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.

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 :)

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.

Sure, but that's also a fine outcome - everyone decides language X sucks and moves to language Y.

If that language Y guarantees things nicer than language X, you've solved the problem :-)

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.