Re: Undefined Behavior Optimizations in C

From	gah4 <gah4@u.washington.edu>
Newsgroups	comp.compilers
Subject	Re: Undefined Behavior Optimizations in C
Date	2023-01-10 15:57 -0800
Organization	Compilers Central
Message-ID	<23-01-035@comp.compilers> (permalink)
References	(1 earlier) <23-01-011@comp.compilers> <23-01-012@comp.compilers> <23-01-017@comp.compilers> <23-01-027@comp.compilers> <23-01-032@comp.compilers>

Show all headers | View raw

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)

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Undefined Behavior Optimizations in C "Lucian Popescu" <lucic71@ctrl-c.club> - 2023-01-05 10:05 +0000
  RE: Undefined Behavior Optimizations in C "Nuno Lopes" <nuno.lopes@tecnico.ulisboa.pt> - 2023-01-05 10:24 +0000
  Re: Undefined Behavior Optimizations in C Spiros Bousbouras <spibou@gmail.com> - 2023-01-05 18:06 +0000
    Re: Undefined Behavior Optimizations in C gah4 <gah4@u.washington.edu> - 2023-01-05 16:22 -0800
      Re: Undefined Behavior Optimizations in C anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-01-06 08:41 +0000
      Re: Undefined Behavior Optimizations in C David Brown <david.brown@hesbynett.no> - 2023-01-06 16:12 +0100
        Re: Undefined Behavior Optimizations in C gah4 <gah4@u.washington.edu> - 2023-01-06 10:33 -0800
          Re: Undefined Behavior Optimizations in C gah4 <gah4@u.washington.edu> - 2023-01-06 11:39 -0800
          Re: Undefined Behavior Optimizations in C Spiros Bousbouras <spibou@gmail.com> - 2023-01-07 12:10 +0000
            Re: Undefined Behavior Optimizations in C antispam@math.uni.wroc.pl - 2023-01-13 20:46 +0000
        Re: Undefined Behavior Optimizations in C Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-09 10:14 +0000
          Re: Re: Undefined Behavior Optimizations in C Jon Chesterfield <jonathanchesterfield@gmail.com> - 2023-01-10 10:46 +0000
            Re: Undefined Behavior Optimizations in C Thomas Koenig <tkoenig@netcologne.de> - 2023-01-11 09:34 +0000
              Re: Undefined Behavior Optimizations in C Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-12 05:21 +0000
                Re: Undefined Behavior Optimizations in C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-12 12:21 -0800
                Re: Undefined Behavior Optimizations in C Thomas Koenig <tkoenig@netcologne.de> - 2023-01-12 21:50 +0000
                Re: Undefined Behavior Optimizations in C Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-15 04:17 +0000
            Re: Undefined Behavior Optimizations in C David Brown <david.brown@hesbynett.no> - 2023-01-11 14:20 +0100
              Re: Undefined Behavior Optimizations in C Spiros Bousbouras <spibou@gmail.com> - 2023-01-18 13:14 +0000
                Re: Undefined Behavior Optimizations in C David Brown <david.brown@hesbynett.no> - 2023-01-18 21:14 +0100
                Re: Undefined Behavior Optimizations in C gah4 <gah4@u.washington.edu> - 2023-01-18 21:10 -0800
                Re: Undefined Behavior Optimizations in C gah4 <gah4@u.washington.edu> - 2023-01-20 10:45 -0800
                Re: Undefined Behavior Optimizations in C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-20 13:54 -0800
                Re: Undefined Behavior Optimizations in C gah4 <gah4@u.washington.edu> - 2023-01-23 18:50 -0800
                Re: Undefined Behavior Optimizations in Fortran "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2023-01-26 21:12 +0000
                Re: Undefined Behavior Optimizations in Fortran gah4 <gah4@u.washington.edu> - 2023-01-26 17:50 -0800
                Re: Undefined Behavior Optimizations in C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2023-01-19 21:18 -0800
                Re: Undefined Behavior Optimizations in C Thomas Koenig <tkoenig@netcologne.de> - 2023-01-20 20:42 +0000
                Re: Undefined Behavior Optimizations in C anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-01-21 11:54 +0000
                Re: Undefined Behavior Optimizations in C anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-01-22 09:56 +0000
                Re: Undefined Behavior Optimizations in C Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-22 07:04 +0000
                Re: Undefined Behavior Optimizations in C Martin Ward <martin@gkc.org.uk> - 2023-01-23 17:12 +0000
          Re: Undefined Behavior Optimizations in C David Brown <david.brown@hesbynett.no> - 2023-01-10 17:32 +0100
            Re: Undefined Behavior Optimizations in C gah4 <gah4@u.washington.edu> - 2023-01-10 15:57 -0800
              Re: Undefined Behavior Optimizations in C David Brown <david.brown@hesbynett.no> - 2023-01-11 14:40 +0100
                Re: Undefined Behavior Optimizations in C gah4 <gah4@u.washington.edu> - 2023-01-11 16:09 -0800
            Re: Undefined Behavior Optimizations in C dave_thompson_2@comcast.net - 2023-01-28 10:35 -0500
  Re: Undefined Behavior Optimizations in C anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-01-06 07:47 +0000
  Re: Undefined Behavior Optimizations in C Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-09 09:10 +0000

csiph-web