Re: Undefined Behavior Optimizations in C

On Wednesday, January 11, 2023 at 3:13:08 PM UTC-8, David Brown wrote:


(snip)


> > Much also assumes ASCII code. Don't tell IBM about that.


> There is usually no requirement for a given piece of C code to be fully
> portable to all conforming compilers. Most C code is quite limited in
> the scope of its use, and it is quite reasonable to assume two's
> complement representation (though /not/ two's complement wrapping on
> overflow), 8-bit char, ASCII characters, etc. It may be fine to assume
> 32-bit int, and perhaps little-endian ordering. These are /warranted/
> assumptions, not unwarranted ones - they are typically reasonable to
> make, and if you want to you can sometimes put compile-time checks so
> that if someone does try to use it out of context, they get an error
> message.


As I noted with the Fortran optimization example from 50 years ago,
this is not a new problem. But IBM documented it (so, as you note, it
is an extension and not UB), and programmers learn to expect it.


And yes I ignored the distinction between implementation defined
and undefined. But that is exactly what happens when actual
people (as opposed to other programs) write programs.


People learn what works and what doesn't. When they need to worry
about endianness or ASCII or two's complement.


Much of the implementation, or undefined, behavior of early Fortran
compilers, later got implemented into the standard. And much didn't,
but enough people believe it did.


If compiler writers remember that they are writing for use by actual
people, who are sometimes imperfect, then it should be fine. Try to
make the changes not too surprising to users.


I don't remember the exact example of surprising UB, but they are out
there.


In any case, I am all for the original project, of studying compilers,
UB, and optimization. If it doesn't really help speed up problems, but
does slow down debugging, maybe it isn't worth doing.

Return to the comp.compilers page.
Search the comp.compilers archives again.