Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #396141

Re: On Undefined Behavior

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.lang.c
Subject Re: On Undefined Behavior
Date 2026-01-04 12:58 +0100
Organization A noiseless patient Spider
Message-ID <10jdkkb$1vilu$1@dont-email.me> (permalink)
References <10j6qdt$3q9n4$1@dont-email.me> <20260102135350.74@kylheku.com> <10jc697$1j15f$1@dont-email.me>

Show all headers | View raw

On 03/01/2026 23:47, highcrew wrote:
> On 1/2/26 11:52 PM, Kaz Kylheku wrote:
>> On 2026-01-01, highcrew <high.crew3868@fastmail.com> wrote:
>> For the situation in your program, it would be unacceptable to have
>> implementations stop translating.
> 
> I can somehow get the idea that it is difficult for the compiler
> to spot the issue, but why do you think it would be unacceptable
> to stop translating?
> 

A C compiler definitely should /not/ stop translating just because it 
finds UB like this - at least, not with "normal" compilation flags. 
(With additional flags, anything is allowable.)

Run-time UB is only a problem if the running program attempts to execute 
it.  So it is only really appropriate for it to be treated as a fatal 
compile-time error if the compiler knows for sure that it will be 
executed (i.e., it can trace all execution paths from the start of 
"main" and see that it is inevitably executed).  That is clearly 
infeasible for the vast majority of such run-time UB.

It is entirely normal that code is full of potential run-time UB :

	extern int xs[10];
	int foo(int i) { return xs[i]; }

The function "foo" has potential UB - but the compiler should not stop 
translating just because you /might/ call it with an inappropriate argument.

Functions that have unavoidable UB, such as the example in this thread, 
are not guaranteed to be called - the compiler cannot reasonably refuse 
to continue compiling.  But it is also fair to say unavoidable UB in a 
function is almost certainly a mistake by the programmer, and a warning 
message (even without specifying any warning flags) would be a very nice 
thing for the compiler to give you.

The C standard requires certain mistakes to require a diagnostic - a 
warning or fatal error message.  It only does that for things that a 
compiler could reasonably be expected to identify, without having to 
simulate run-time conditions, or consider multiple translation units at 
once.



>> We really want just a warning (at
>> least by default; in specific project and situations, developers
>> could elect to treat certain warnings as fatal, even standard-required
>> warnings.)
> 
> Even a warning would be enough though.  Btw, my typical way of
> working is to enable -Werror while developing, but I don't like
> to force it in general.  That would be an interesting digression,
> but definitely OT.
> 

(I too have "-Werror" enabled, at least once my initial builds are 
somewhat solidified - it means you can't lose an important warning 
message somewhere in the output of your build process.)

>> The second new thing is that to diagnose this, we need to make
>> diagnosis dependent on reachability.
>>
>> We want a rule which is something like "whenever the body of
>> a function, or an initializing expression for an external definition
>> reaches an expression which has unconditional undefined behavior
>> that is not an unreachability assertion and not a documented
>> extension, a warning diagnostic must be issued".
> 
> That's an interesting perspective: reachability.
> Would you say that the incriminated piece of code is UB only if it
> is reachable in the final program, therefore it is acceptable
> to keep it as long as unreachable?
> 
> Now that I think of it, the __builtin_unreachable() implemented
> by popular compilers is technically UB *if reached* :)
> 

"unreachable()" is now standard, in C23.  But that may be what Kaz is 
referring to as "an unreachability assertion".

And AFAIUI gcc and clang/llvm have an "UB" instruction or statement in 
their internal formats, and will use that for "__builtin_unreachable()" 
and also when generating code from your example.

>> This kind of diagnostic would be a good thing in my opinion; just
>> nobody has stepped up to the plate because of the challenges:
>>
>> - introducing the concept of a warning versus error diagnostic.
>>
>> - defining a clear set of rules for trivial reachability which
>>    can catch the majority of these situations without too much
>>    complexity. (The C++ rules for functions that return value
>>    reaching their end without a return statement can be used
>>    as inspiration here.)
>>
>> - specifying exactly what "statically obvious" undefined behavior
>>    is and how positively determine that a certain expression
>>    exhibits it.
> Now I'm wondering how much work it requires to properly define
> the rules that the standard mandates!
> 

Um, the standard defines the rules - that's the point.  So your question 
is really "how much work did it take to write the C standard?".  I don't 
think that's what you meant.

> As for me the main take-away is that the detection of certain UB
> is non-trivial, it would be very evil if the standard was mandating
> some nearly-impossible task to the compiler!
> 

The standard is quite lenient on what it requires from C compilers 
(though most don't follow all its rules by default).  Static warnings 
are a matter of quality of implementation, not requirements of the 
language.  This lets people write relatively small and simple C 
compilers if they want, while also giving big toolchains the freedom to 
add lots more checking and developer help.

> 
>  > (The C++ rules for functions that return value
>  >    reaching their end without a return statement can be used
>  >    as inspiration here.)
> 
> C++ does *what*?? I'm definitely not up to speed with C++, but
> I totally have missed that.  Could you please tell me the name
> of this bizarre feature? I *need* to look it up :D
> 

I believe the difference is in the behaviour of a function that is 
declared to return a value (i.e., not "void") but which exits without a 
returning value.  In C, this is allowed - but it is UB to attempt to use 
the non-existent return value.  In C++, it is UB to fail to return a 
value - which is far easier for a compiler to diagnose.

So if you have :

	int foo(void) { }

	int bar(void) { return foo(); }

then in C++, the UB is in the definition of "foo", while in C it is in 
the run-time use of "foo" inside "bar".

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-01 22:54 +0100
  Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-02 00:26 +0200
    Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-01 23:57 +0100
    Re: On Undefined Behavior Kaz Kylheku <046-301-5902@kylheku.com> - 2026-01-02 22:56 +0000
      Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-03 20:48 +0200
      Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-04 14:38 +0100
        Re: On Undefined Behaviour Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-04 21:42 +0000
          Re: On Undefined Behaviour candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2026-01-07 06:40 +0000
        Re: On Undefined Behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-04 16:58 -0500
          Re: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-05 08:49 +0100
  Re: On Undefined Behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-01 17:49 -0500
  Re: On Undefined Behavior antispam@fricas.org (Waldek Hebisch) - 2026-01-02 05:53 +0000
    Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-02 17:38 +0100
      Re: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-03 13:30 +0100
  Re: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-02 10:31 +0100
    Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-02 17:51 +0100
      Re: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-03 13:42 +0100
        Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-03 14:42 +0100
          Re: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-03 17:51 +0100
            Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-04 00:20 +0100
  Re: On Undefined Behavior Kaz Kylheku <046-301-5902@kylheku.com> - 2026-01-02 22:52 +0000
    Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-03 23:47 +0100
      Re: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-04 12:58 +0100
  Re: On Undefined Behavior Andrey Tarasevich <noone@noone.net> - 2026-01-03 07:53 -0800
    Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-04 00:15 +0100
      NULL dereference in embedded [was: On Undefined Behavior] highcrew <high.crew3868@fastmail.com> - 2026-01-04 00:25 +0100
        Re: NULL dereference in embedded [was: On Undefined Behavior] James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-03 18:59 -0500
          Re: NULL dereference in embedded [was: On Undefined Behavior] scott@slp53.sl.home (Scott Lurndal) - 2026-01-04 15:51 +0000
            Re: NULL dereference in embedded [was: On Undefined Behavior] David Brown <david.brown@hesbynett.no> - 2026-01-05 08:55 +0100
        Re: NULL dereference in embedded [was: On Undefined Behavior] Andrey Tarasevich <noone@noone.net> - 2026-01-03 17:24 -0800
          Re: NULL dereference in embedded [was: On Undefined Behavior] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-04 02:19 +0000
            Re: NULL dereference in embedded [was: On Undefined Behavior] James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-03 21:31 -0500
              Re: NULL dereference in embedded [was: On Undefined Behavior] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-04 04:52 +0000
                Re: NULL dereference in embedded [was: On Undefined Behavior] James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-04 13:00 -0500
                Re: NULL dereference in embedded [was: On Undefined Behavior] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-04 21:22 +0000
                Re: NULL dereference in embedded [was: On Undefined Behavior] James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-04 16:53 -0500
                Re: NULL dereference in embedded [was: On Undefined Behavior] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-05 00:16 +0000
                Re: NULL dereference in embedded [was: On Undefined Behavior] James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-05 06:41 -0500
                Re: NULL dereference in embedded [was: On Undefined Behavior] David Brown <david.brown@hesbynett.no> - 2026-01-05 09:07 +0100
            Re: NULL dereference in embedded [was: On Undefined Behavior] scott@slp53.sl.home (Scott Lurndal) - 2026-01-04 15:56 +0000
          Re: NULL dereference in embedded [was: On Undefined Behavior] Andrey Tarasevich <noone@noone.net> - 2026-01-03 18:44 -0800
        Re: NULL dereference in embedded [was: On Undefined Behavior] David Brown <david.brown@hesbynett.no> - 2026-01-04 17:16 +0100
          Re: NULL dereference in embedded [was: On Undefined Behavior] antispam@fricas.org (Waldek Hebisch) - 2026-01-06 13:08 +0000
            Re: NULL dereference in embedded [was: On Undefined Behavior] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-06 21:59 +0000
            Re: NULL dereference in embedded [was: On Undefined Behavior] Andrey Tarasevich <noone@noone.net> - 2026-01-07 20:48 -0800
              Re: NULL dereference in embedded [was: On Undefined Behavior] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-08 23:56 +0000
  Re: On Undefined Behavior Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-03 23:14 +0000
  Re: On Undefined Behavior "Paul J. Lucas" <paul@lucasmail.org> - 2026-01-03 17:10 -0800
    Re: On Undefined Behavior highcrew <high.crew3868@fastmail.com> - 2026-01-04 12:51 +0100
      Re: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-05 15:39 +0100
        Re: On Undefined Behavior "Paul J. Lucas" <paul@lucasmail.org> - 2026-01-06 18:08 -0800
          Re: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-07 11:25 +0100
          Re: On Undefined Behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-07 06:31 -0500
          Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-07 14:10 +0200
  Re: On Undefined Behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-09 01:42 -0800
    Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-09 14:36 +0200
      Re: On Undefined Behavior Kaz Kylheku <046-301-5902@kylheku.com> - 2026-01-09 20:14 +0000
        Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-10 18:19 +0200
        Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-10 18:41 +0200
          Re: On Undefined Behavior Kaz Kylheku <046-301-5902@kylheku.com> - 2026-01-13 23:31 +0000
            Re: On Undefined Behavior antispam@fricas.org (Waldek Hebisch) - 2026-01-14 03:57 +0000
            Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-14 10:47 +0200
            Re: On Undefined Behavior Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-14 14:49 +0000
        Re: On Undefined Behavior Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-10 17:08 +0000
      Re: On Undefined Behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-11 11:48 -0800
        Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-11 22:52 +0200
          Re: On Undefined Behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-11 22:53 -0800
            Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-12 11:44 +0200
              Re: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-12 20:29 -0500
          Re: On Undefined Behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 05:29 -0800
  Re: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-09 15:54 +0200
    Re: On Undefined Behavior wij <wyniijj5@gmail.com> - 2026-01-10 00:08 +0800
  UB or not UB? was: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-12 16:28 +0200
    Re: UB or not UB? was: On Undefined Behavior bart <bc@freeuk.com> - 2026-01-12 15:58 +0000
      Re: UB or not UB? was: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-12 20:08 +0200
        Re: UB or not UB? was: On Undefined Behavior scott@slp53.sl.home (Scott Lurndal) - 2026-01-12 20:02 +0000
          Re: UB or not UB? was: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-12 21:09 -0500
            Re: UB or not UB? was: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-13 11:31 +0200
              Re: UB or not UB? was: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-13 22:21 -0500
        Re: UB or not UB? was: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-13 22:19 -0500
          Re: UB or not UB? was: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-14 09:35 +0100
            Re: UB or not UB? was: On Undefined Behavior antispam@fricas.org (Waldek Hebisch) - 2026-01-14 17:23 +0000
              Re: UB or not UB? was: On Undefined Behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-14 12:53 -0800
            Re: UB or not UB? was: On Undefined Behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-14 14:43 -0800
              Re: UB or not UB? was: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-15 11:45 +0100
                Re: UB or not UB? was: On Undefined Behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-15 06:16 -0500
                Re: UB or not UB? was: On Undefined Behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-15 04:04 -0800
                Re: UB or not UB? was: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-15 13:56 +0100
                Re: UB or not UB? was: On Undefined Behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 05:34 -0800
                Re: UB or not UB? was: On Undefined Behavior scott@slp53.sl.home (Scott Lurndal) - 2026-01-15 15:10 +0000
                Re: UB or not UB? was: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-15 16:23 +0100
      Re: UB or not UB? was: On Undefined Behavior Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-13 21:54 +0000
        Re: UB or not UB? was: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-13 21:58 -0500
          Re: UB or not UB? was: On Undefined Behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-13 22:02 -0800
            Re: UB or not UB? was: On Undefined Behavior Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-14 14:24 +0000
              Re: UB or not UB? was: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-14 16:48 +0200
    Re: UB or not UB? was: On Undefined Behavior Andrey Tarasevich <noone@noone.net> - 2026-01-12 08:03 -0800
      Re: UB or not UB? was: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-12 19:36 +0200
        Re: UB or not UB? was: On Undefined Behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-12 12:03 -0800
          Re: UB or not UB? was: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-12 22:41 +0200
            Re: UB or not UB? was: On Undefined Behavior David Brown <david.brown@hesbynett.no> - 2026-01-13 09:12 +0100
            Re: UB or not UB? was: On Undefined Behavior pa@see.signature.invalid (Pierre Asselin) - 2026-01-13 20:19 +0000
            Re: UB or not UB? was: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-13 22:20 -0500
            Re: UB or not UB? was: On Undefined Behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 21:53 -0800
          Re: UB or not UB? was: On Undefined Behavior Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-13 23:53 +0000
            Re: UB or not UB? was: On Undefined Behavior Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-14 08:06 +0000
        Re: UB or not UB? was: On Undefined Behavior Andrey Tarasevich <noone@noone.net> - 2026-01-13 08:11 -0800
          Re: UB or not UB? was: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-13 22:10 -0500
          Re: UB or not UB? was: On Undefined Behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-01 22:53 -0800
        Re: UB or not UB? was: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-13 22:20 -0500
    Re: UB or not UB? was: On Undefined Behavior "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-12 20:35 -0500
      Re: UB or not UB? was: On Undefined Behavior Michael S <already5chosen@yahoo.com> - 2026-01-13 11:07 +0200
  Re: On Undefined Behavior Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-13 20:37 +0000

csiph-web