Hacker News new | ask | show | jobs
by lmm 3896 days ago
> The original code was ANSI C and thus should compile fine on all compilers compatible with ANSI C, the new code is not as each compiler will decide to handle undefined behavior differently.

Except 40% of the original code already wasn't ANSI C.

> Either you'll make the exact compiler a hard dependency (i.e. it always has to be compiled with gcc and fails to build with everything else), or it will produce "correct" binaries on some compilers and "incorrect" binaries on others. That's hardly an improvement.

Having code that was broken under GCC not be broken under GCC absolutely is an improvement, particularly since in fact this kind of code often works on every other extant compiler.

> make the ANSI C more strict by adding the guarantees to the standard. Which is not going to happen, I guess.

Standards tend to codify existing practice. There's no reason the standard couldn't be made stricter - but the way we get to there from here is if the major compilers implement stricter restrictions and can show that they can be implemented consistently and users find them useful. GCC has been willing to do that kind of innovation for other parts of the standard.

1 comments

> Except 40% of the original code already wasn't ANSI C.

Then why complain that ANSI C compiler gets confused by it?

> Having code that was broken under GCC not be broken under GCC absolutely is an improvement, particularly since in fact this kind of code often works on every other extant compiler.

No, the code does not work on every other compiler. And if it is, there's no guarantee it will stay like that.

> Standards tend to codify existing practice. There's no reason the standard couldn't be made stricter - but the way we get to there from here is if the major compilers implement stricter restrictions and can show that they can be implemented consistently and users find them useful. GCC has been willing to do that kind of innovation for other parts of the standard.

AFAIK some of the limitations are there because of non-traditional platforms - some of them may be a thing of the past so removing them would be OK, but some are not (and thus won't be removed from the standard). And one of the points of ANSI C (and POSIX) is to define global guarantees, not per-platform ones.

> Then why complain that ANSI C compiler gets confused by it?

Because I didn't ask for an ANSI C-and-not-a-penny-more compiler. Nobody wants that. Back in the day the GNU project made a point of going against standards when the standardized behaviour was user-unfriendly (POSIX_ME_HARDER etc.)

> No, the code does not work on every other compiler.

In many of these cases it does work on all other major compilers, or all other relevant platforms for that particular codebase.

> And if it is, there's no guarantee it will stay like that.

So what? That doesn't make it better to break it now.

> one of the points of ANSI C (and POSIX) is to define global guarantees, not per-platform ones.

Which is why it's GCC's (or any other compiler's) responsibility to define the per-platform guarantees.