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.
with -Wall -Werror ?
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
As in the chiptune dude? Can anybody confirm it's the same guy?
That's a highly specific thing ... who funded this again? :-P
Lost at C:>. Found at C.
Now we know what really took place at Volkswagen and the rigged emissions. Underhanded C!
typedef double float_t;
Nice solution, but I'm not sure it would not get detected with proper coding standard, peer reviews, and testing. But it would depend on a human factor. Plus compiler would likely give a warning for overriding a typedef.
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.
Um, what? It has nothing to do with the function name.
Yes, -Wall is good way to find code smells.
For obfuscated code, I suggest -Larry -Wall.
This header file defines float_t as double precision, although by default math.h defines float_t as single precision.
Sorry. Technically float_t is a type, and defined as single precision. double_t is the correct type for double float
Regardless, redefining the float_t to being double is the problem, when it is already defined as something else. Sending back for a fix would solve the problem, rather than redefining what float_t means. Of course, you can remain pendantic and not get the point I was making. It is solvable, by sending the code back for revision, to remove the problematic re-defining of the type. In this case, using double_t instead of redefining float_t .
http://pubs.opengroup.org/onli...
float_t
A real-floating type at least as wide as float.
double_t
A real-floating type at least as wide as double, and at least as wide as float_t.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
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!
My understanding if float_t means one thing here, and another thing there, then it isn't defined correctly. Standard Math.h files expect it one way, changing that in one place, but not passing that change on to every other possible place is problematic, and as a programmer SHOULD cause flags. Compilers don't care, as you stated.
It should have been flagged somewhere by someone or something. Because it wasn't, looked innocuous and has a potential for HUGE problems down the road. Just because something is allowed, doesn't make it right. Lots of huge bugs are created that way.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
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.