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?
Now we know what really took place at Volkswagen and the rigged emissions. Underhanded C!
Does any program compile with -Wall -Werror?
The Nuclear Threat Initiative.
This year's challenge (detailed below) is a real-world problem in nuclear verification, sponsored by and designed in partnership with the Nuclear Threat Initiative (http://www.nti.org/), a nonprofit, nonpartisan organization working to reduce the threat of nuclear, chemical and biological weapons.
"Government is like fire; a handy servant, but a dangerous master." -- George Washington
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.
yes? mine do. Always.
if there's a warning you fix it. Or if it's unfixable you suppress that specific warning.
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.
Yes, -Wall is good way to find code smells.
For obfuscated code, I suggest -Larry -Wall.
Some of the "warning" -Wall checks and calls out are asinine. There not worth the time to "fix" just to make the compiler happy.
I cannot remember a concrete, very specific case from ages past where this was true. But in general, and after seeing a ton of code, if you start from the beginning with -Wall -Werror and don't let that shit go, it goes a long way towards maintainability.
Additionally, the moment you let that discipline go, things begin to go to shit. And before you know it, you have your compilation logs fulled with warnings that you cannot turn off because of the off change one of them might be relevant, and no way to go back and clean that shit up because the technical debt is too huge.
I hate working with projects were -Wall -Werror is not the norm for the bulk of source code. In the general case, warnings are latent errors and you might as well squash them without mercy before the creep out of your control.
They carefully didn't include math.h (where float_t is normally defined) in the same file (but did elsewhere, to create the error.)
Even better, the floating point precision was defined in the spec as being a double. Therefore, the error looks benign. Certainly, a quick code review may thing it's actually setting the precision of the math library.
And, if discovered, it looks super-innocent.
This kind of solution is why I didn't enter. I had some ideas (all based around NaN poisoning), but knew that I didn't have a clear and clever solution like this.
Maybe next year
Your ad here. Ask me how!
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!
Some of the "warning" -Wall checks and calls out are asinine. There not worth the time to "fix" just to make the compiler happy.
Dude, when the folks who wrote the compiler that you're using to turn your source code into a runnable program took the time to do extra work to warn you that your seemingly-correct source code does something dodgy, you'd probably be best served to listen to them.
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.
Hi,
In the winning entry there is no cast or "conversion" per se. It has one C file that calls a function and another C file that implements the function, with a mismatch between the types of the call and the implementation. Neither file by itself is performing any conversion or doing something wrong that can be caught by static analysis; the bug is caused by a mismatch between the code in two object files. This would only be caught by a tool that would examine the two files together, but it would not be caught by the compilation of either part.
We've actually seen a number of past entries that used this same basic trick to mismatch a call and an implementation. A previous winning entry managed to redefine the time() function as time_t time(void) instead of time_t time(time_t *ptr), avoiding a compiler warning by using the extern keyword. That's a neat trick because barely anyone uses the argument to time(), and after writing t=time(NULL) hundreds of times, it's easy to completely miss a call like t=time(). This caused a call to time() with the wrong number of arguments, so that another variable on the stack was used to hilarious effect.
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.
The Iranian government.
Nullius in verba
Exactly. The people commenting ITT that "it's easy to fix" or "the compiler should give a warning" or whatever miss the point entirely. This is sneaky use of a language feature.