Re: Undefined Behavior Optimizations in C

gah4 <gah4@u.washington.edu>
Tue, 10 Jan 2023 15:57:07 -0800 (PST)

          From comp.compilers

Related articles
[6 earlier articles]
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-06)
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-06)
Re: Undefined Behavior Optimizations in C spibou@gmail.com (Spiros Bousbouras) (2023-01-07)
Re: Undefined Behavior Optimizations in C 864-117-4973@kylheku.com (Kaz Kylheku) (2023-01-09)
Re: Undefined Behavior Optimizations in C 864-117-4973@kylheku.com (Kaz Kylheku) (2023-01-09)
Re: Undefined Behavior Optimizations in C david.brown@hesbynett.no (David Brown) (2023-01-10)
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-10)
Re: Undefined Behavior Optimizations in C tkoenig@netcologne.de (Thomas Koenig) (2023-01-11)
Re: Undefined Behavior Optimizations in C david.brown@hesbynett.no (David Brown) (2023-01-11)
Re: Undefined Behavior Optimizations in C david.brown@hesbynett.no (David Brown) (2023-01-11)
Re: Undefined Behavior Optimizations in C gah4@u.washington.edu (gah4) (2023-01-11)
Re: Undefined Behavior Optimizations in C 864-117-4973@kylheku.com (Kaz Kylheku) (2023-01-12)
Re: Undefined Behavior Optimizations in C Keith.S.Thompson+u@gmail.com (Keith Thompson) (2023-01-12)
[16 later articles]
| List of all articles for this month |

From: gah4 <gah4@u.washington.edu>
Newsgroups: comp.compilers
Date: Tue, 10 Jan 2023 15:57:07 -0800 (PST)
Organization: Compilers Central
References: 23-01-009 23-01-011 23-01-012 23-01-017 23-01-027 23-01-032
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="8236"; mail-complaints-to="abuse@iecc.com"
Keywords: optimize, C
Posted-Date: 10 Jan 2023 19:57:07 EST
In-Reply-To: 23-01-032

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)


Post a followup to this message

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