> Changing syntax and semantics should not be impossible (it's being done),
What change? There has never been a version of the C language, all the
way from K&Rv1 to the present, that defined signed overflow.
The problem is the previous compilers never took advantage of the permission
to make it undefined and so people wrote programs that were technically
incorrect, but worked with existing compilers.
> By real warnings in compilers that wake people to the
> fact that the semantics of their coding style are in the process of being
> altered, so watch out.
The problem, as has been discussed here at length, is that there's no WAY
for the compiler to determine in any reliable manner, whether a particular
construct is depending on wrapping semantics or not.
Suppose you have the straightforward:
int a = b + c;
Might b+c overflow in that program? Might the author be depending on that
overflow wrapping? There's simply no way to know.
You certainly don't want to produce a warning on every addition operation
where you can't prove that it won't overflow because that would produce so
many warnings as to be useless.
That means it's impossible to do what you are suggesting, which is to
warn about every usage whose definition would "change", as you consider it.
The BEST you can do is to look at each time that the compiler would want
to make a transformation (optimization) based on assuming that overflow
is undefined and warn about THAT if it can't prove that the overflow
can't occur. However, there are still two problems with this:
(1) It will only detect cases where the present optimization technology
would make a change; later advances in the compiler might affect more of them.
(2) The false-positive rate of such a warning might well ALSO be too high
to be useful if, in real programs, most of these cases DO NOT in practice
overflow, but the compiler isn't able to prove it.
> why is it all these language lawyers are spending so much time
> arguing over what everyone ought to be able to understand from the
> documents themselves?
The discussions in this thread aren't what is valid standard C: everybody
agrees on that. The issue is what we should do about the cases in legacy
programs that are "invalid".
> My main point is simply this: change the language when there is compelling
> need.
There is no proposal to change the language, nor would this list be the proper
place for such a proposal anyway.
> WRT strict aliasing, I've never seen any data that indicated that the
> language change was compelling. Consequently, as best I can tell it
> was a marginal optimization improvement. So, I doubt its value.
The problem there is that strict aliasing is in itself not an optimization,
but merely provides data for use by nearly all the optimizers. So the best
we can do is to measure the effect having that data has on optimizers right
now. As optimizers get more sophisticated, there are two competing effects:
first, they might be able to do a better job at getting the data without
relying on type-based aliasing. But also, they might make better use of
the data.
The other thing about aliasing rules is that code that violates them is
also harder to read and understand because knowing what can and can't
alias is also important to the human reader. So there are multiple reasons
for wanting code to conform to these rules.
