There's an interesting subtlety mentioned in the author's explanation <a href="http://www.linusakesson.net/programming/underhanded/2015-spoilers.pdf" rel="nofollow">http://www.linusakesson.net/programming/underhanded/2015-spo...</a> that doesn't seem to be mentioned here: the preprocessing had to be carefully designed because the squashing also amplifies any residual noise, so if that wasn't thoroughly removed the comparison would fail because it'd mostly be comparing noise rather than signal. While the type confusion is the only suspicious thing, the rest of the code did have to be crafted to make it work, it's just that the other changes are reasonable and non-suspicious.
I think this is my favorite Underhanded C submission ever. One simple ambiguity, applied with breathtaking precision and effectiveness. Puts me in mind of an old essay of Zed's: <a href="http://zedshaw.com/archive/the-master-the-expert-the-programmer/" rel="nofollow">http://zedshaw.com/archive/the-master-the-expert-the-program...</a>
And if, like me, you didn't knew what this contest was about, the explanation is one click away [1]:<p>"a competition that challenges coders to solve a simple data processing problem by writing innocent-looking C code that is as readable, clear, and seemingly trustworthy as possible, yet covertly implements a malicious function."<p>[1] <a href="http://underhanded-c.org/_page_id_5.html" rel="nofollow">http://underhanded-c.org/_page_id_5.html</a>
The winning entry reminds me of Linus (Torvalds)' viewpoint on typedefs: <a href="http://yarchive.net/comp/linux/typedefs.html" rel="nofollow">http://yarchive.net/comp/linux/typedefs.html</a><p>Those for whom the name Linus <i>Åkesson</i> is unfamiliar are highly encouraged to visit his site at <a href="http://www.linusakesson.net/" rel="nofollow">http://www.linusakesson.net/</a> --- he has a lot of other interesting articles on programming and the demoscene.
Here's Linus in a completely different but awesome context: <a href="https://www.youtube.com/watch?v=m1pchpDD5EU" rel="nofollow">https://www.youtube.com/watch?v=m1pchpDD5EU</a>
I wonder how many of them would be caught using a very strict compiler flag regime.<p>For the winner, perhaps the gcc flag, <i>-Wmissing-prototypes</i> would catch it?
This is really great!<p>Reading through the source made me look twice though, as I am used to writing C++ so seeing variables defined but not initialised, non-const array starting points as parameters with a separate length parameter (instead of just a reference to a container or a const reference to enforce read-only nature), memcpy instead of copy constructors or copy assignment operators.<p>Basically, it made me realise how impossible I would find it to write good C!<p>Really clever entry though, very impressive. I spotted all the issues I mentioned above, looking for mistakes in them and completely missing the actual problem.
Beautiful. I'd just looked up float_t, and realized that typedef'ing it to double was almost certainly a 'tell', but I still failed to spot the failure to include the header.<p>I presumed it was simply going to try to slip in a 'float' for a 'float_t' and hope it wasn't noticed, although it seemed unlikely to be a winning strategy.<p>One other thing that seemed odd was the continued use 'double' after the typedef. I wonder if there's a way to make it work where all the usages are replaced by 'float_t'.
here is the blog entry of linux akesson, the winner about his entry.
<a href="https://news.ycombinator.com/edit?id=11032712" rel="nofollow">https://news.ycombinator.com/edit?id=11032712</a>