Re: Undefined Behavior Optimizations in C

On Tuesday, January 10, 2023 at 2:00:57 PM UTC-8, David Brown wrote:


(big snip)


> It is particularly harmful when programmers think there is such a thing
> as "de facto defined". That's an oxymoron. If the behaviour is
> defined, it is defined. If it is not defined, it is not defined. If it
> is not defined and a programmer makes unwarranted and incorrect
> assumptions about what they think it means, then the programmer needs to
> update his or her understanding of the language. They don't get to
> blame the compiler or the compiler writer for not making the same
> unfounded assumptions that they did.


A lot of C code assumes two's complement. I believe Unisys still sells
ones' complement hardware, and so that code might have UB, but often
people know that it will only run on two's complement machines.


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


I remember comments in some routines in the IBM PL/I (F)
library, such as:


THE OPERATION OF THIS MODULE DEPENDS UPON AN INTERNAL
REPRESENTATION OF THE EXTERNAL CHARACTER SET WHICH IS
EQUIVALENT TO THE ONE USED AT ASSEMBLY TIME. THE CODING
HAS BEEN ARRANGED SO THAT REDEFINITION OF ''CHARACTER''
CONSTANTS, BY REASSEMBLY, WILL RESULT IN A CORRECT
MODULE FOR THE NEW DEFINITIONS.


I have never seen that in C programs.


As I noted in another thread, Java has a rule that the compiler be
able to determine that a variable is given a value before it is used.
It is a fatal compilation error if it can't.


If C compilers had a fatal compilation error when they found
suspicious UB, I could live with that. Maybe it means doing
something to convince the compiler, even if it really is still UB.


Remember, much of the data breaches we hear about
(and also the ones we don't) are due to buffer overflow
in C programs. Make it easier, instead of harder, for programmers
to avoid buffer problems.


(snip)

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