Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've become convinced that the original ANSI committee didn't intend to create the monster they did. The reason is that Dennis Ritchie wrote a submission to the committee¹ that described the ‘noalias’ proposal as “a license for the compiler to undertake aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs”, and, that “[i]t negates every brave promise X3J11 ever made about codifying existing practices, preserving the existing body of code, and keeping (dare I say it?) ‘the spirit of C.’”

Those comments describe what ‘undefined behaviour’ turned in to. The only reason dmr and others didn't make the same objections to it is that nobody realized at the time what the committee wording implied.

¹ available here: https://www.lysator.liu.se/c/dmr-on-noalias.html



I don't buy these arguments. Suppose you have a little bit of UB:

    char foo[10];
    foo[10] = x;
That's a buffer overflow, and a clever attacker can supply input for which this really will format your hard drive. Writing a standard that allows literally anything for this particular example of UB but somehow requires sensible behavior for other types of UB is not obviously possible. Merely saying that it can't happen doesn't make it so.


I believe the committee's intent was, as they stated, to ‘codify existing practice’. That means that the compiler generates code for the statement as written (in this case, a store into location foo+10) and what happens when it runs is up to the machine and not the compiler's problem.

At the time ANSI C was under way, I was working on a commercial C compiler and following developments closely. I don't think anyone anticipated what ‘undefined behavior’ would turn into.


The problem with that approach is it inhibits a lot of perfectly-sensible optimizations. If you force the compiler to leave it up to the machine, you force it to preserve the same stack layout, the same memory write, and the same execution order relative to everything else.

You basically forbid it from working with an execution model at any level higher than "a giant array of bytes," because now you have to preserve the naive behavior of that giant array of bytes. But this is not really useful for correct programs.

The committee's intent may have (accidentally, indirectly) been to codify compilers that do very little optimization, but that doesn't mean it was a good idea.


Thanks for the link!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: