"a compiler's behavior should give considerable weight to how the language is used more than taking a literal view of what the words mean in the spec."
This is generally true, but the problem in this case is the committee history of a lot of what is being complained about shows it was added specifically to let compilers reason the way they do.
The committee didn't sit down and say "hey, this should be undefined, because it sucked". Instead, what happened is committee members and compiler writers sat down and said the compiler guys said "if you make this undefined, we can optimize this thing over here better", and the committee said "great, sounds awesome".
Complaining that the compiler writers then go and do that is misguided :)
(This covers most of the specific examples given, BTW. There are other examples where he dismissively claims that what should happen is obvious.)
The whole thing is like complaining that people follow the law, instead of the spirit of the law.
The question I have is whether committee members are sufficiently representative of programmers in the trenches, and whether committee members are sufficiently informed about the impact of their saying, "great, sounds awesome".
Sometimes yes, sometimes no. But in some sense, it doesn't matter.
They are the ones defining C. If people don't like it, they should create Cgood or whatever.
This has been tried before, and it has never caught on.
I'm not worried. If the programmers in the trenches really hate it so much, C will eventually die off in favor of something better :)
To be fair Cgood doesn't catch on because no compiler vendors implement it, and the C standards committe is at least somewhat beholden to the compiler vendors because if the compiler vendors en-masse decided not to implement their standard, then the standard isn't worth the paper it's printed on.
Compiler vendors are people, and in fact, if you don't like that set of people, there are plenty of vendors who have forks :)
IE if you don't like gcc 4.8's treatment of behavior, it's not like there aren't 50 different arm forks from different vendors you can use, with or without their SOC's.
Yet none of these vendors have apparently heard enough from customers that they have made what are pretty simple patches.
It's really, really hard to sell someone on a non-standard implementation of a popular language like C. For example, I've had customers beg me to add an extension to C. I implement it, and present it to them. They refuse to use it - because then their code would be dependent on a non-Standard feature.
The solution (for me, anyway) was to create an entirely new language. The changes that nobody wanted in C (not because they were bad, but because they were non-Standard) found plenty of traction and users in D.
This is a very good observation. The exception is strict subsets though; there are plenty of people using MISRA, and that's an extremely restrictive subset of C. Similarly this would be a dialect of C that is identical in behavior for conforming C programs, rather than C with some extensions.
> This is entirely true, but at the same time:
Compiler vendors are people, and in fact, if you don't like that set of people, there are plenty of vendors who have forks :)
With all due respect, but that sounds a bit like "if you don't like this particular law, you're always free to try a coup/revolution/run your own country".
I don't know much about the situation in standardized C, but I would argue that the point of standards is to reduce fragmentation and discuss language features in a way that all implementation can benefit from it. Demanding that you break the standard if you don't like a part of it kind of defeats that point, I think.
A different (and IMO more sensible) approach is shown by the WHATWG developing HTML5. Even though input primarily comes from browser vendors (which would be the equivalent to compiler vendors here), there is a rather strict requirement that new features must break a little as possible existing usage of HTML and should never introduce new security vulnerabilities. (Where those requirements collide, the second one takes precedence). This is done by extensive studies of how HTML is used "in the wild".
"With all due respect, but that sounds a bit like "if you don't like this particular law, you're always free to try a coup/revolution/run your own country".
"
IMHO, it's closer to, if you don't like SF, you can move to any of the cities around it :)
"Demanding that you break the standard if you don't like a part of it kind of defeats that point, I think."
Which, humorously, is precisely what Anton wants in some cases.
"A different (and IMO more sensible) approach is shown by the WHATWG developing HTML5. Even though input primarily comes from browser vendors (which would be the equivalent to compiler vendors here), there is a rather strict requirement that new features must break a little as possible existing usage of HTML and should never introduce new security vulnerabilities. (Where those requirements collide, the second one takes precedence). This is done by extensive studies of how HTML is used "in the wild"."
This is in actuality, how most of C/C++ is developed. With a bit more formality due to it being an international standard.
The truth is this code has pretty much never had defined behavior.
This is generally true, but the problem in this case is the committee history of a lot of what is being complained about shows it was added specifically to let compilers reason the way they do.
The committee didn't sit down and say "hey, this should be undefined, because it sucked". Instead, what happened is committee members and compiler writers sat down and said the compiler guys said "if you make this undefined, we can optimize this thing over here better", and the committee said "great, sounds awesome".
Complaining that the compiler writers then go and do that is misguided :)
(This covers most of the specific examples given, BTW. There are other examples where he dismissively claims that what should happen is obvious.)
The whole thing is like complaining that people follow the law, instead of the spirit of the law.