Slashdot Mirror
Winner of the 2015 Underhanded C Contest Announced (underhanded-c.org)
Xcott Craver writes: The Underhanded C contest results have now been announced. This time the contest challenge was to cause a false match in a nuclear inspection scenario, allowing a country to remove fissile material from a warhead without being noticed. The winner receives $1000 from the Nuclear Threat Initiative.
As in the chiptune dude? Can anybody confirm it's the same guy?
Hi,
I didn't mention it on the page, but the C file that #includes that header doesn't #include math.h, so there is no typedef overridden. A second C file #includes math.h without #including that header.
I've enjoyed these over the years. My personal favorite was the "English to Pig Latin" translator whose source code looked like ASCII Art for a pig.
But really, if you can do stuff like that, you can do pretty much anything. So what's the point, really? Where's the challenge?
A much more interesting contest would be to write C code that's simple and understandable. Yes, I said it, simple and understandable and in C. There's a challenge to bend the minds of the world's greatest programmers.
It's not being redefined. Because of the way the C compiler works, it has different values at different points of compilation, but never does one definition get overwritten by another one. (Analogous to many wrong API based errors). The fact you would think it's checked against by the compiler makes this cleverer, because you'd expect the machine to throw a warning if it was actually redefined.
And float_t is supposed to define (at least as wide as a float) the commonly used float type in this environment. According to the given spec, the min float type was supposed to be a double. If that were consistently included in all files, it would have actually triggered errors if you ever used a regular float function. The problem was not enough redefining
Your ad here. Ask me how!
It has been a requirement in all of my jobs. I work on things where many lives are dependent on correct function of the software.
The stupid thing is that C++ name mangling would already catch this problem at link time, and every modern C/C++ compiler already has code to support this, except that it's only activated for the much loved/unloved function overloading.
If GCC/clang in C mode generated mangled names into object files when compiling C programs (as purely informative records), the linker could diagnose this kind of problem as optional linkage errors—mighty darn useful, optional linkage errors.
This is a violation of the type system pure and simple, but one that doesn't compromise any specific compilation unit. That leaves the linker as the next line of defense, but like to keep our C linkers in dark boxes full of trust-me horse shit.