2nd Underhanded C Contest Begins
This year’s challenge: ridiculous performance degredation
For this year’s challenge, imagine you are an application developer for an OS vendor. You must write portable C code that will inexplicably taaaaaake a looooooong tiiiiime when compiled and run on a competitor’s OS. The program is supposed to read a set of words on stdin, and print a frequency count of unique words in lexicographical order. Essentially the output should match the command line…
tr "[:space:]" "n" | sort | awk 'length($0)>0' | uniq -c
I really like the Underhanded C Contest, in part because I think almost all new C code written today is a mistake, and anything that helps to ‘rebrand’ C is a fine thing. Sure, there’s places where C makes sense, but the power of C and the C library to explode on their user mean that developers have to spend time thinking about issues which today’s language design and compiler can handle. Sure, for embedded or operating system code, C may well make sense, as it does as those places where optimization is needed.
The contest also helps create a corpus of code with unusual properties. Having that code is a first step along research into determining if code is malicious. There’s an extent to which that’s an unsolvable problem. As Ka-Ping Yee has pointed out, if you download a program that encrypts all the files on your disk, that’s great if you’ve downloaded PGP, not so good if you thought it was a game. The only thing that differs is user expectation. [“Guidelines and Strategies for Secure Interaction Design,” in Security and Usability, which unfortunately is not online.] Clearly, there are limits to what can be done in determining intent, but it may be possible to detect sneakiness in code. That would be neat.
The Underhanded C Contest page. (Previously here, “2005 Underhanded C Contest” and “2005 Underhanded C Contest Winners Announced.” Kate photo by operationbringanimalshome on Flikr.)