Groups > comp.lang.c > #396062 > unrolled thread

On Undefined Behavior

Started by	highcrew <high.crew3868@fastmail.com>
First post	2026-01-01 22:54 +0100
Last post	2026-01-13 20:37 +0000
Articles	20 on this page of 113 — 18 participants

Back to article view | Back to comp.lang.c

  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

Page 1 of 6 [1] 2 3 4 5 6 Next page →

#396062 — On Undefined Behavior

From	highcrew <high.crew3868@fastmail.com>
Date	2026-01-01 22:54 +0100
Subject	On Undefined Behavior
Message-ID	<10j6qdt$3q9n4$1@dont-email.me>

Hello,

While I consider myself reasonably good as C programmer, I still
have difficulties in understanding undefined behavior.
I wonder if anyone in this NG could help me.

Let's take an example.  There's plenty here:
https://en.cppreference.com/w/c/language/behavior.html
So let's focus on https://godbolt.org/z/48bn19Tsb

For the lazy, I report it here:

   int table[4] = {0};
   int exists_in_table(int v)
   {
       // return true in one of the first 4 iterations
       // or UB due to out-of-bounds access
       for (int i = 0; i <= 4; i++) {
           if (table[i] == v) return 1;
       }
       return 0;
   }

This is compiled (with no warning whatsoever) into:

   exists_in_table:
           mov     eax, 1
           ret
   table:
           .zero   16


Well, this is *obviously* wrong. And sure, so is the original code,
but I find it hard to think that the compiler isn't able to notice it,
given that it is even "exploiting" it to produce very efficient code.

I understand the formalism: the resulting assembly is formally
"correct", in that UB implies that anything can happen.
Yet I can't think of any situation where the resulting assembly
could be considered sensible.  The compiled function will
basically return 1 for any input, and the final program will be
buggy.

Wouldn't it be more sensible to have a compilation error, or
at least a warning?  The compiler will be happy even with -Wall -Wextra
-Werror.

There's plenty of documentation, articles and presentations that
explain how this can make very efficient code... but nothing
will answer this question: do I really want to be efficiently
wrong?

I mean, yes I would find the problem, thanks to my 100% coverage
unit testing, but couldn't the compiler give me a hint?

Could someone drive me into this reasoning? I know there is a lot of
thinking behind it, yet everything seems to me very incorrect!
I'm in deep cognitive dissonance here! :) Help!

-- 
High Crew

[toc] | [next] | [standalone]

#396063

From	Michael S <already5chosen@yahoo.com>
Date	2026-01-02 00:26 +0200
Message-ID	<20260102002616.000050c9@yahoo.com>
In reply to	#396062

On Thu, 1 Jan 2026 22:54:05 +0100
highcrew <high.crew3868@fastmail.com> wrote:

> Hello,
> 
> While I consider myself reasonably good as C programmer, I still
> have difficulties in understanding undefined behavior.
> I wonder if anyone in this NG could help me.
> 
> Let's take an example.  There's plenty here:
> https://en.cppreference.com/w/c/language/behavior.html
> So let's focus on https://godbolt.org/z/48bn19Tsb
> 
> For the lazy, I report it here:
> 
>    int table[4] = {0};
>    int exists_in_table(int v)
>    {
>        // return true in one of the first 4 iterations
>        // or UB due to out-of-bounds access
>        for (int i = 0; i <= 4; i++) {
>            if (table[i] == v) return 1;
>        }
>        return 0;
>    }
> 
> This is compiled (with no warning whatsoever) into:
> 
>    exists_in_table:
>            mov     eax, 1
>            ret
>    table:
>            .zero   16
> 
> 
> Well, this is *obviously* wrong. And sure, so is the original code,
> but I find it hard to think that the compiler isn't able to notice it,
> given that it is even "exploiting" it to produce very efficient code.
> 
> I understand the formalism: the resulting assembly is formally
> "correct", in that UB implies that anything can happen.
> Yet I can't think of any situation where the resulting assembly
> could be considered sensible.  The compiled function will
> basically return 1 for any input, and the final program will be
> buggy.
> 
> Wouldn't it be more sensible to have a compilation error, or
> at least a warning?  The compiler will be happy even with -Wall
> -Wextra -Werror.
> 
> There's plenty of documentation, articles and presentations that
> explain how this can make very efficient code... but nothing
> will answer this question: do I really want to be efficiently
> wrong?
> 
> I mean, yes I would find the problem, thanks to my 100% coverage
> unit testing, but couldn't the compiler give me a hint?
> 
> Could someone drive me into this reasoning? I know there is a lot of
> thinking behind it, yet everything seems to me very incorrect!
> I'm in deep cognitive dissonance here! :) Help!
> 

IMHO, for compiler that eliminated all comparisons (I assume that it was
gcc -O2/-O3) an absence of warning is a bug.
It's worth reporting.

And it has nothing to do with C standard and what considered UB by the
standard and what not. It's a bug from practical POV and I believe that
gcc maintainers will admit it and will fix it. Eventually, that is. Not
too quickly.

[toc] | [prev] | [next] | [standalone]

#396065

From	highcrew <high.crew3868@fastmail.com>
Date	2026-01-01 23:57 +0100
Message-ID	<10j6u4h$3q9n6$1@dont-email.me>
In reply to	#396063

On 1/1/26 11:26 PM, Michael S wrote:
> On Thu, 1 Jan 2026 22:54:05 +0100
> highcrew <high.crew3868@fastmail.com> wrote:
>> For the lazy, I report it here:
>>
>>     int table[4] = {0};
>>     int exists_in_table(int v)
>>     {
>>         // return true in one of the first 4 iterations
>>         // or UB due to out-of-bounds access
>>         for (int i = 0; i <= 4; i++) {
>>             if (table[i] == v) return 1;
>>         }
>>         return 0;
>>     }
>>
>> This is compiled (with no warning whatsoever) into:
>>
>>     exists_in_table:
>>             mov     eax, 1
>>             ret
>>     table:
>>             .zero   16
>>
 > [...]
 >
> IMHO, for compiler that eliminated all comparisons (I assume that it was
> gcc -O2/-O3) an absence of warning is a bug.

Correct: -O2.  Same code compiled with -O0: 
https://godbolt.org/z/xE61j3PdM -> Still no warnings, although it will 
at least contain
the `return 0`.

Which doesn't mean it is better: the code is obviously wrong, and
*I think* the compiler should whine.

 > It's worth reporting.

Do you think so? I think everybody already knows...

First off, this example is mentioned since forever on the cppreference
website.  Secondly, no warning is issued by Clang either.

Again, with this I don't mean the compilers are behaving correctly.
I just think this situation is well known.

-- 
High Crew

[toc] | [prev] | [next] | [standalone]

#396095

From	Kaz Kylheku <046-301-5902@kylheku.com>
Date	2026-01-02 22:56 +0000
Message-ID	<20260102145245.213@kylheku.com>
In reply to	#396063

On 2026-01-01, Michael S <already5chosen@yahoo.com> wrote:
> On Thu, 1 Jan 2026 22:54:05 +0100
> highcrew <high.crew3868@fastmail.com> wrote:
>
>> Hello,
>> 
>> While I consider myself reasonably good as C programmer, I still
>> have difficulties in understanding undefined behavior.
>> I wonder if anyone in this NG could help me.
>> 
>> Let's take an example.  There's plenty here:
>> https://en.cppreference.com/w/c/language/behavior.html
>> So let's focus on https://godbolt.org/z/48bn19Tsb
>> 
>> For the lazy, I report it here:
>> 
>>    int table[4] = {0};
>>    int exists_in_table(int v)
>>    {
>>        // return true in one of the first 4 iterations
>>        // or UB due to out-of-bounds access
>>        for (int i = 0; i <= 4; i++) {
>>            if (table[i] == v) return 1;
>>        }
>>        return 0;
>>    }
>> 
>> This is compiled (with no warning whatsoever) into:
>> 
>>    exists_in_table:
>>            mov     eax, 1
>>            ret
>>    table:
>>            .zero   16
>> 
>> 
>> Well, this is *obviously* wrong. And sure, so is the original code,
>> but I find it hard to think that the compiler isn't able to notice it,
>> given that it is even "exploiting" it to produce very efficient code.
>> 
>> I understand the formalism: the resulting assembly is formally
>> "correct", in that UB implies that anything can happen.
>> Yet I can't think of any situation where the resulting assembly
>> could be considered sensible.  The compiled function will
>> basically return 1 for any input, and the final program will be
>> buggy.
>> 
>> Wouldn't it be more sensible to have a compilation error, or
>> at least a warning?  The compiler will be happy even with -Wall
>> -Wextra -Werror.
>> 
>> There's plenty of documentation, articles and presentations that
>> explain how this can make very efficient code... but nothing
>> will answer this question: do I really want to be efficiently
>> wrong?
>> 
>> I mean, yes I would find the problem, thanks to my 100% coverage
>> unit testing, but couldn't the compiler give me a hint?
>> 
>> Could someone drive me into this reasoning? I know there is a lot of
>> thinking behind it, yet everything seems to me very incorrect!
>> I'm in deep cognitive dissonance here! :) Help!
>> 
>
> IMHO, for compiler that eliminated all comparisons (I assume that it was
> gcc -O2/-O3) an absence of warning is a bug.

A bug against which requirement, articulated where?

> And it has nothing to do with C standard and what considered UB by the
> standard and what not.

It has everything to do with it, unfortunately. It literally has nothing
to do with anything else, in fact.

That function either finds a match in the four array elements and
returns 1, or else its behavior is undefined.

Therefore there is no situation under which it is /required/ to return
anything other than 1.

You literally cannot write a test case which tests for the "return 0",
such that the test case has well-defined behavior.

All well-defined test cases can only test for 1 being returned.

And that is satisfied by machine code which unconditionally returns 1.

There is no requirement anywhere that the function requires a
diagnostic; not in ISO C and not in any GCC documentation.

Therefore your bug report would have to be not about the compiler
behavior but about the lack of the requirement.

This is a difficult problem: writing the requirement /in a good way/
that covers many cases is not easy, and that's before you implement
anything in the compiler.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#396115

From	Michael S <already5chosen@yahoo.com>
Date	2026-01-03 20:48 +0200
Message-ID	<20260103204810.00004d79@yahoo.com>
In reply to	#396095

On Fri, 2 Jan 2026 22:56:55 -0000 (UTC)
Kaz Kylheku <046-301-5902@kylheku.com> wrote:

> On 2026-01-01, Michael S <already5chosen@yahoo.com> wrote:
> > On Thu, 1 Jan 2026 22:54:05 +0100
> > highcrew <high.crew3868@fastmail.com> wrote:
> >  
> >> Hello,
> >> 
> >> While I consider myself reasonably good as C programmer, I still
> >> have difficulties in understanding undefined behavior.
> >> I wonder if anyone in this NG could help me.
> >> 
> >> Let's take an example.  There's plenty here:
> >> https://en.cppreference.com/w/c/language/behavior.html
> >> So let's focus on https://godbolt.org/z/48bn19Tsb
> >> 
> >> For the lazy, I report it here:
> >> 
> >>    int table[4] = {0};
> >>    int exists_in_table(int v)
> >>    {
> >>        // return true in one of the first 4 iterations
> >>        // or UB due to out-of-bounds access
> >>        for (int i = 0; i <= 4; i++) {
> >>            if (table[i] == v) return 1;
> >>        }
> >>        return 0;
> >>    }
> >> 
> >> This is compiled (with no warning whatsoever) into:
> >> 
> >>    exists_in_table:
> >>            mov     eax, 1
> >>            ret
> >>    table:
> >>            .zero   16
> >> 
> >> 
> >> Well, this is *obviously* wrong. And sure, so is the original code,
> >> but I find it hard to think that the compiler isn't able to notice
> >> it, given that it is even "exploiting" it to produce very
> >> efficient code.
> >> 
> >> I understand the formalism: the resulting assembly is formally
> >> "correct", in that UB implies that anything can happen.
> >> Yet I can't think of any situation where the resulting assembly
> >> could be considered sensible.  The compiled function will
> >> basically return 1 for any input, and the final program will be
> >> buggy.
> >> 
> >> Wouldn't it be more sensible to have a compilation error, or
> >> at least a warning?  The compiler will be happy even with -Wall
> >> -Wextra -Werror.
> >> 
> >> There's plenty of documentation, articles and presentations that
> >> explain how this can make very efficient code... but nothing
> >> will answer this question: do I really want to be efficiently
> >> wrong?
> >> 
> >> I mean, yes I would find the problem, thanks to my 100% coverage
> >> unit testing, but couldn't the compiler give me a hint?
> >> 
> >> Could someone drive me into this reasoning? I know there is a lot
> >> of thinking behind it, yet everything seems to me very incorrect!
> >> I'm in deep cognitive dissonance here! :) Help!
> >>   
> >
> > IMHO, for compiler that eliminated all comparisons (I assume that
> > it was gcc -O2/-O3) an absence of warning is a bug.  
> 
> A bug against which requirement, articulated where?
> 
> > And it has nothing to do with C standard and what considered UB by
> > the standard and what not.  
> 
> It has everything to do with it, unfortunately. It literally has
> nothing to do with anything else, in fact.
> 
> That function either finds a match in the four array elements and
> returns 1, or else its behavior is undefined.
> 
> Therefore there is no situation under which it is /required/ to return
> anything other than 1.
> 
> You literally cannot write a test case which tests for the "return 0",
> such that the test case has well-defined behavior.
> 
> All well-defined test cases can only test for 1 being returned.
> 
> And that is satisfied by machine code which unconditionally returns 1.
> 
> There is no requirement anywhere that the function requires a
> diagnostic; not in ISO C and not in any GCC documentation.
> 
> Therefore your bug report would have to be not about the compiler
> behavior but about the lack of the requirement.
> 
> This is a difficult problem: writing the requirement /in a good way/
> that covers many cases is not easy, and that's before you implement
> anything in the compiler.
> 

The text above is an example of languagelowyerish speak. I don't like
it.

gcc maintainer would want to fix it, because they actually care about
quality of implementation.
Now, being in majority not atypical representative of males of great
ape species, the care even more about always feeling right, having last
word, etc...
Which means that the process of convincing the to make a fix requires
wisdom.

[toc] | [prev] | [next] | [standalone]

#396142

From	highcrew <high.crew3868@fastmail.com>
Date	2026-01-04 14:38 +0100
Message-ID	<10jdqfo$20hbp$1@dont-email.me>
In reply to	#396095

On 1/2/26 11:56 PM, Kaz Kylheku wrote:
> You literally cannot write a test case which tests for the "return 0",
> such that the test case has well-defined behavior.
> 
> All well-defined test cases can only test for 1 being returned.
> 
> And that is satisfied by machine code which unconditionally returns 1.

I appreciate the nuance, or at least think I understand what you are
saying here. A test that aims at spotting UB is necessarily using
UB-tainted code, so it might even pass against all odds.

Then it looks to me like this is one of those situations where practice
beats theory. Unit testing, sanitizers, fuzzers... these tools will
reveal the defect with a very high likelihood.

Not differently from halting problem: sure, it is theoretically
impossible to understand if a program will terminate, but in practical
terms, if you expect it to take less than 1 second and it takes more
than 10, you area already hitting ^C and conjecturing that something
went horribly wrong :D

-- 
High Crew

[toc] | [prev] | [next] | [standalone]

#396148 — Re: On Undefined Behaviour

From	Lawrence D’Oliveiro <ldo@nz.invalid>
Date	2026-01-04 21:42 +0000
Subject	Re: On Undefined Behaviour
Message-ID	<10jemrk$2bdcd$1@dont-email.me>
In reply to	#396142

On Sun, 4 Jan 2026 14:38:00 +0100, highcrew wrote:

> Not differently from halting problem: sure, it is theoretically
> impossible to understand if a program will terminate, but in
> practical terms, if you expect it to take less than 1 second and it
> takes more than 10, you area already hitting ^C and conjecturing
> that something went horribly wrong :D

What do Windows users hit instead of CTRL/C? Because CTRL/C means
something different to them, doesn’t it?

[toc] | [prev] | [next] | [standalone]

#396250 — Re: On Undefined Behaviour

From	candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
Date	2026-01-07 06:40 +0000
Subject	Re: On Undefined Behaviour
Message-ID	<slrn10lrvop.2u5s0.candycanearter07@candydeb.host.invalid>
In reply to	#396148

Lawrence D’Oliveiro <ldo@nz.invalid> wrote at 21:42 this Sunday (GMT):
> On Sun, 4 Jan 2026 14:38:00 +0100, highcrew wrote:
>
>> Not differently from halting problem: sure, it is theoretically
>> impossible to understand if a program will terminate, but in
>> practical terms, if you expect it to take less than 1 second and it
>> takes more than 10, you area already hitting ^C and conjecturing
>> that something went horribly wrong :D
>
> What do Windows users hit instead of CTRL/C? Because CTRL/C means
> something different to them, doesn’t it?


ctrl-alt-delete?
-- 
user <candycane> is generated from /dev/urandom

[toc] | [prev] | [next] | [standalone]

#396150

From	James Kuyper <jameskuyper@alumni.caltech.edu>
Date	2026-01-04 16:58 -0500
Message-ID	<10jenqh$26t2v$2@dont-email.me>
In reply to	#396142

On 2026-01-04 08:38, highcrew wrote:
...
> Not differently from halting problem: sure, it is theoretically
> impossible to understand if a program will terminate,

That's an incorrect characterization of the halting problem. There are
many programs where it's entirely feasible, and even easy, to determine
whether they will halt. What has been proven is that there must be some
programs that for which it cannnot be done.

[toc] | [prev] | [next] | [standalone]

#396153

From	David Brown <david.brown@hesbynett.no>
Date	2026-01-05 08:49 +0100
Message-ID	<10jfqdq$2l1be$1@dont-email.me>
In reply to	#396150

On 04/01/2026 22:58, James Kuyper wrote:
> On 2026-01-04 08:38, highcrew wrote:
> ...
>> Not differently from halting problem: sure, it is theoretically
>> impossible to understand if a program will terminate,
> 
> That's an incorrect characterization of the halting problem. There are
> many programs where it's entirely feasible, and even easy, to determine
> whether they will halt. What has been proven is that there must be some
> programs that for which it cannnot be done.

That is also imprecise.  The halting problem is about proving that there 
is no /single/ algorithm (or equivalently, program) that can determine 
the halting status of /all/ programs.  It is not about the existence of 
a program whose halting status cannot be determined - it is that for any 
systematic method you might use to determine the halting status of 
programs, there are always programs for which that method won't work.

In the context of static error checking for runtime UB, this means that 
no matter how smart a static analyser is, you can always write a program 
with runtime UB that the analyser won't identify for you.  You can then 
extend that analyser to cover this new case, but no matter how great you 
make your analyser, there will always be programs with UB that it can't 
identify.

[toc] | [prev] | [next] | [standalone]

#396064

From	James Kuyper <jameskuyper@alumni.caltech.edu>
Date	2026-01-01 17:49 -0500
Message-ID	<10j6tm4$3qt4n$1@dont-email.me>
In reply to	#396062

On 2026-01-01 16:54, highcrew wrote:
> Hello,
> 
> While I consider myself reasonably good as C programmer, I still
> have difficulties in understanding undefined behavior.
> I wonder if anyone in this NG could help me.
> 
> Let's take an example.  There's plenty here:
> https://en.cppreference.com/w/c/language/behavior.html
> So let's focus on https://godbolt.org/z/48bn19Tsb
> 
> For the lazy, I report it here:
> 
>    int table[4] = {0};
>    int exists_in_table(int v)
>    {
>        // return true in one of the first 4 iterations
>        // or UB due to out-of-bounds access
>        for (int i = 0; i <= 4; i++) {
>            if (table[i] == v) return 1;
>        }
>        return 0;
>    }
> 
> This is compiled (with no warning whatsoever) into:
> 
>    exists_in_table:
>            mov     eax, 1
>            ret
>    table:
>            .zero   16
> 
> 
> Well, this is *obviously* wrong. And sure, so is the original code,
> but I find it hard to think that the compiler isn't able to notice it,
> given that it is even "exploiting" it to produce very efficient code.
> 
> I understand the formalism: the resulting assembly is formally
> "correct", in that UB implies that anything can happen.
> Yet I can't think of any situation where the resulting assembly
> could be considered sensible.  The compiled function will
> basically return 1 for any input, and the final program will be
> buggy.

I agree.

> Wouldn't it be more sensible to have a compilation error, or
> at least a warning?  The compiler will be happy even with -Wall -Wextra
> -Werror.

The rule that this code violates is still violated if an array is
accessed through a pointer, from a module which has no knowledge of the
actual length of the array. As a result, it does not make sense for the
standard to require diagnosis of all such violations.
However, implementations are free to diagnose violations such as this
one, where it would be perfectly feasible to do so. Whether or not
implementations actually do so is considered a matter of "Quality of
Implementation" (QoI), and therefore outside the scope of the standard.
Generating code that is only justified because the behavior is
undefined, and failing to diagnose the problem, seems to me to be very
bad QoI.

[toc] | [prev] | [next] | [standalone]

#396067

From	antispam@fricas.org (Waldek Hebisch)
Date	2026-01-02 05:53 +0000
Message-ID	<10j7mg7$1v1a$1@paganini.bofh.team>
In reply to	#396062

highcrew <high.crew3868@fastmail.com> wrote:
> Hello,
> 
> While I consider myself reasonably good as C programmer, I still
> have difficulties in understanding undefined behavior.
> I wonder if anyone in this NG could help me.
> 
> Let's take an example.  There's plenty here:
> https://en.cppreference.com/w/c/language/behavior.html
> So let's focus on https://godbolt.org/z/48bn19Tsb
> 
> For the lazy, I report it here:
> 
>   int table[4] = {0};
>   int exists_in_table(int v)
>   {
>       // return true in one of the first 4 iterations
>       // or UB due to out-of-bounds access
>       for (int i = 0; i <= 4; i++) {
>           if (table[i] == v) return 1;
 >       }
>       return 0;
>   }
> 
> This is compiled (with no warning whatsoever) into:
> 
>   exists_in_table:
>           mov     eax, 1
>           ret
>   table:
>           .zero   16
> 
> 
> Well, this is *obviously* wrong. And sure, so is the original code,
> but I find it hard to think that the compiler isn't able to notice it,
> given that it is even "exploiting" it to produce very efficient code.
> 
> I understand the formalism: the resulting assembly is formally
> "correct", in that UB implies that anything can happen.
> Yet I can't think of any situation where the resulting assembly
> could be considered sensible.  The compiled function will
> basically return 1 for any input, and the final program will be
> buggy.

You do not get the formalism: compiler applies a lot transformations
which are supposed to be correct for programs obeying the C rules.
However, compiler does not understand the program.  It may notice
details that you missed, but it act essentialy blindly on
information it has.  And most transformations have only limited
info (storing all things that compiler infers would take a lot
of memory and searching all info would take a lot of time).

Code that you see is a result of many transformations, possibly
hundreds or more.  The result is a conseqence of all steps,
but it could be hard to isolate a single "silly" step.

> Wouldn't it be more sensible to have a compilation error, or
> at least a warning?  The compiler will be happy even with -Wall -Wextra
> -Werror.

This case looks reasonably easy: when compiling 'exists_in_table'
the compiler had declaration of 'table' and knows it size is 4.
Compiler generated its output probably after noticing that
the loop would produce out of bound reference.  So with some
extra effort it should be possible to generate a diagnostic.
But in general, instead of array you may have a pointer without
bound information.  Or upper bound may be variable.  As James
wrote, for such reasons C standard does not require a diagnostic.
Also, in the past gcc and clang did not generate diagnostics
in such situation.  gcc is very complex beast and adding
diagnostics now may require nontrivial effort.

BTW: I expect that eventually gcc will warn.  Ideologicaly,
using various string functions can overflow buffers in
similar ways.  In the past such buffers overflow just generated
some (possibly "working") code.  Now most such uses report
warnings.  In fact, this problem looks like an outlier.

> There's plenty of documentation, articles and presentations that
> explain how this can make very efficient code... but nothing
> will answer this question: do I really want to be efficiently
> wrong?

By using C you implicitely gave "yes" as an answer.

> I mean, yes I would find the problem, thanks to my 100% coverage
> unit testing, but couldn't the compiler give me a hint?

Since it gave no hint it probably could not.  In cases when it
can it warns (at least when you activate warnings).

> Could someone drive me into this reasoning? I know there is a lot of
> thinking behind it, yet everything seems to me very incorrect!
> I'm in deep cognitive dissonance here! :) Help!
> 

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#396078

From	highcrew <high.crew3868@fastmail.com>
Date	2026-01-02 17:38 +0100
Message-ID	<10j8sa9$ha1u$1@dont-email.me>
In reply to	#396067

On 1/2/26 6:53 AM, Waldek Hebisch wrote:
> highcrew <high.crew3868@fastmail.com> wrote:
> 
> You do not get the formalism: compiler applies a lot transformations
> which are supposed to be correct for programs obeying the C rules.
> However, compiler does not understand the program.  It may notice
> details that you missed, but it act essentialy blindly on
> information it has.  And most transformations have only limited
> info (storing all things that compiler infers would take a lot
> of memory and searching all info would take a lot of time).
> 
> Code that you see is a result of many transformations, possibly
> hundreds or more.  The result is a conseqence of all steps,
> but it could be hard to isolate a single "silly" step.
> [...]

Thanks for your answer.

So you are basically saying that spotting such a problem is
way more difficult than optimizing it? And indeed so difficult that the
compiler fails at it?

>> There's plenty of documentation, articles and presentations that
>> explain how this can make very efficient code... but nothing
>> will answer this question: do I really want to be efficiently
>> wrong?
> 
> By using C you implicitely gave "yes" as an answer.

Wait, I don't think that makes sense.
If we are talking about a legitimate limitation of the compilers, as you
seem to suggest, then it is a different situation.

Perhaps it would be more proper to say that, by using C, one implicitly
accepts to take the burden of writing UB-free code.
The compiler can't guarantee that it will detect UB, so the contract
is: you get a correct program if you write correct code.

-- 
High Crew

[toc] | [prev] | [next] | [standalone]

#396104

From	David Brown <david.brown@hesbynett.no>
Date	2026-01-03 13:30 +0100
Message-ID	<10jb25q$17gcb$1@dont-email.me>
In reply to	#396078

On 02/01/2026 17:38, highcrew wrote:
> On 1/2/26 6:53 AM, Waldek Hebisch wrote:
>> highcrew <high.crew3868@fastmail.com> wrote:
>>
>> You do not get the formalism: compiler applies a lot transformations
>> which are supposed to be correct for programs obeying the C rules.
>> However, compiler does not understand the program.  It may notice
>> details that you missed, but it act essentialy blindly on
>> information it has.  And most transformations have only limited
>> info (storing all things that compiler infers would take a lot
>> of memory and searching all info would take a lot of time).
>>
>> Code that you see is a result of many transformations, possibly
>> hundreds or more.  The result is a conseqence of all steps,
>> but it could be hard to isolate a single "silly" step.
>> [...]
> 
> Thanks for your answer.
> 
> So you are basically saying that spotting such a problem is
> way more difficult than optimizing it? And indeed so difficult that the
> compiler fails at it?
> 
>>> There's plenty of documentation, articles and presentations that
>>> explain how this can make very efficient code... but nothing
>>> will answer this question: do I really want to be efficiently
>>> wrong?
>>
>> By using C you implicitely gave "yes" as an answer.
> 

When code contains UB, all guarantees are out the window.  There is no 
"right" answer, so it doesn't really make sense to ask if you are 
getting the wrong answer efficiently or inefficiently.  In effect, 
because you are not giving the compiler valid correct C code, it can't 
know what you really want - you can't reasonably complain about what you 
get in response.  Compilers are not mind readers.

(Of course compilers try to go beyond the requirements of the C 
language, to be helpful development aids rather than just "pure" 
compilers.  And while good compilers /are/ helpful, there is always room 
for improvement.)

> Wait, I don't think that makes sense.
> If we are talking about a legitimate limitation of the compilers, as you
> seem to suggest, then it is a different situation.
> 
> Perhaps it would be more proper to say that, by using C, one implicitly
> accepts to take the burden of writing UB-free code.
> The compiler can't guarantee that it will detect UB, so the contract
> is: you get a correct program if you write correct code.
> 

That's a good way to phrase it, IMHO.

The C language standards (together with any documented extensions, 
modifications, or implementation-defined behaviour in the 
implementation) provides a contract.  You, as the programmer, guarantee 
to write correct source code.  In return, the compiler guarantees to 
generate correct object code.  If you fail on your part, and write UB in 
your code, the compiler is under no obligation to give you anything 
useful in return.

[toc] | [prev] | [next] | [standalone]

#396070

From	David Brown <david.brown@hesbynett.no>
Date	2026-01-02 10:31 +0100
Message-ID	<10j8399$9grh$1@dont-email.me>
In reply to	#396062

On 01/01/2026 22:54, highcrew wrote:
> Hello,
> 
> While I consider myself reasonably good as C programmer, I still
> have difficulties in understanding undefined behavior.
> I wonder if anyone in this NG could help me.
> 
> Let's take an example.  There's plenty here:
> https://en.cppreference.com/w/c/language/behavior.html
> So let's focus on https://godbolt.org/z/48bn19Tsb
> 
> For the lazy, I report it here:
> 
>    int table[4] = {0};
>    int exists_in_table(int v)
>    {
>        // return true in one of the first 4 iterations
>        // or UB due to out-of-bounds access
>        for (int i = 0; i <= 4; i++) {
>            if (table[i] == v) return 1;
>        }
>        return 0;
>    }
> 
> This is compiled (with no warning whatsoever) into:
> 
>    exists_in_table:
>            mov     eax, 1
>            ret
>    table:
>            .zero   16
> 
> 
> Well, this is *obviously* wrong. And sure, so is the original code,
> but I find it hard to think that the compiler isn't able to notice it,
> given that it is even "exploiting" it to produce very efficient code.
> 

Since the original code is wrong, it doesn't make sense to ask if the 
generated object code is right or wrong.  This principle was understood 
from the days of mechanical computers: 
<https://www.brainyquote.com/quotes/charles_babbage_141832>

However, it /does/ make sense to ask whether the compiler could have 
been more helpful in pointing out your mistake - and clearly, in theory 
at least, the answer is yes.

Compilers first parse the source code into an internal format.  Then 
they run through this in a series of passes, detecting errors and 
generating warnings, manipulating the code for optimisation, generating 
new types of internal formats, and so on.  For modern compilers there 
will be scores of passes.  Ideally, the ordering of these passes is such 
that the pass that figures out the size of "table" and the range of the 
loop variable will come before the pass that issues out-of-bounds 
warnings, and that will come before the pass that figures out that the 
"return 0;" cannot be reached without passing through UB and thus the 
only possible return value for the function is 1.  For many optimisation 
passes, once the compiler has figured out a way to simplify the code, 
some aspects (such as paths leading up to UB that have been eliminated) 
are lost, and the compiler can't see the problem (and therefore can't 
issue a diagnostic) later on.

Unfortunately here, the passes are not ordered ideally for catching this 
source code bug.  I think it is inevitable that such situations will 
arise - no matter how the passes are ordered, you are going to be able 
to find samples where there is a bug that can easily be spotted by a 
human reader but which is not diagnosed by the compiler.  Change the 
pass order to one that will catch this situation, and another bug will 
now go undiagnosed.  Compiler writers do strive to catch what they can, 
but they must also balance compile times, compiler complexity, and of 
course other demands on their own development time.  Sometimes that 
means things can appear simple and obvious to the user, but would 
require unwarranted effort to implement in the compiler.

I had a little look in the gcc bugzilla, but could not find any issue 
that directly matches this case.  So I think it is worthwhile if you 
file it in as a gcc bug.  (It is not technically a "bug", but it is 
definitely an "opportunity for improvement".)  If the gcc passes make it 
hard to implement as a normal warning, it may still be possible to add 
it to the "-fanalyzer" passes.

> I understand the formalism: the resulting assembly is formally
> "correct", in that UB implies that anything can happen.
> Yet I can't think of any situation where the resulting assembly
> could be considered sensible.  The compiled function will
> basically return 1 for any input, and the final program will be
> buggy.
> 
> Wouldn't it be more sensible to have a compilation error, or
> at least a warning?  The compiler will be happy even with -Wall -Wextra
> -Werror.
> 
> There's plenty of documentation, articles and presentations that
> explain how this can make very efficient code... but nothing
> will answer this question: do I really want to be efficiently
> wrong?

You are asking if you want the generated code to be efficiently wrong or 
inefficiently wrong?

> 
> I mean, yes I would find the problem, thanks to my 100% coverage
> unit testing, but couldn't the compiler give me a hint?

You can also make use of run-time sanitizers that are ideal for catching 
this sort of thing (albeit with an inevitable speed overhead).

<https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html>

> 
> Could someone drive me into this reasoning? I know there is a lot of
> thinking behind it, yet everything seems to me very incorrect!
> I'm in deep cognitive dissonance here! :) Help!
> 

Basically, gcc is a great tool, but not it is not perfect.  Reporting 
such issues can help improve it, but there are no guarantees.

[toc] | [prev] | [next] | [standalone]

#396079

From	highcrew <high.crew3868@fastmail.com>
Date	2026-01-02 17:51 +0100
Message-ID	<10j8t2q$ha1u$2@dont-email.me>
In reply to	#396070

On 1/2/26 10:31 AM, David Brown wrote:
> However, it /does/ make sense to ask whether the compiler could have 
> been more helpful in pointing out your mistake - and clearly, in theory 
> at least, the answer is yes.
 > [...]

Thanks for the clarification.

Yes, I'm exactly wondering if the compiler shouldn't reject that code
to begin with.  I'm not expecting to enter wrong code and get a
working program.  That would be dark magic.

So you are basically confirming what I inferred from Waldek Hebisch's
answer: it is actually quite hard for the compiler to spot it. So we
live with it.

> I had a little look in the gcc bugzilla, but could not find any issue 
> that directly matches this case.  So I think it is worthwhile if you 
> file it in as a gcc bug.  (It is not technically a "bug", but it is 
> definitely an "opportunity for improvement".)  If the gcc passes make it 
> hard to implement as a normal warning, it may still be possible to add 
> it to the "-fanalyzer" passes.

Erm... I will considering filing an "opportunity for improvement"
ticket then, thank you.

>> There's plenty of documentation, articles and presentations that
>> explain how this can make very efficient code... but nothing
>> will answer this question: do I really want to be efficiently
>> wrong?
> 
> You are asking if you want the generated code to be efficiently wrong or 
> inefficiently wrong?

I was asking if it is reasonable to accept as valid a program which
is wrong, and make it optimized in its wrong behavior.

What I could not grasp is the difficulty of the job.
To quote your own words:

 > Sometimes that means things can appear simple and obvious to the user,
 > but would require unwarranted effort to implement in the compiler."

> You can also make use of run-time sanitizers that are ideal for catching 
> this sort of thing (albeit with an inevitable speed overhead).
> 
> <https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html>

Yes, I'm aware of this instruments, but I'm not very knowledgeable about
it. I'd like to learn more, and I'll need to spend time doing so.

Thanks!

-- 
High Crew

[toc] | [prev] | [next] | [standalone]

#396105

From	David Brown <david.brown@hesbynett.no>
Date	2026-01-03 13:42 +0100
Message-ID	<10jb2rr$17gcb$2@dont-email.me>
In reply to	#396079

On 02/01/2026 17:51, highcrew wrote:
> On 1/2/26 10:31 AM, David Brown wrote:
>> However, it /does/ make sense to ask whether the compiler could have 
>> been more helpful in pointing out your mistake - and clearly, in 
>> theory at least, the answer is yes.
>  > [...]
> 
> Thanks for the clarification.
> 
> Yes, I'm exactly wondering if the compiler shouldn't reject that code
> to begin with.  I'm not expecting to enter wrong code and get a
> working program.  That would be dark magic.
> 
> So you are basically confirming what I inferred from Waldek Hebisch's
> answer: it is actually quite hard for the compiler to spot it. So we
> live with it.

I think it is fair to say that if it were easy to detect this case 
within the structure of existing compilers, they would do so already. 
The fact that both gcc and clang fail to produce warnings, despite 
having significant differences in their internal structures and the 
details of their passes, shows that it is not as easy at it might 
appear.  And James has explained why the C standards can't make 
detection of this kind of fault a language requirement.

But it is still worth reporting the simple test case to gcc (and clang) 
to see if they are able to improve their warnings.

> 
>> I had a little look in the gcc bugzilla, but could not find any issue 
>> that directly matches this case.  So I think it is worthwhile if you 
>> file it in as a gcc bug.  (It is not technically a "bug", but it is 
>> definitely an "opportunity for improvement".)  If the gcc passes make 
>> it hard to implement as a normal warning, it may still be possible to 
>> add it to the "-fanalyzer" passes.
> 
> Erm... I will considering filing an "opportunity for improvement"
> ticket then, thank you.

"Opportunity for improvement" tickets are the driving force behind a lot 
of open source software features, so please do file it.  Post the 
bugzilla link here once you get some feedback - it would be good to see 
if there is likely to be an improvement in the warnings.

> 
>>> There's plenty of documentation, articles and presentations that
>>> explain how this can make very efficient code... but nothing
>>> will answer this question: do I really want to be efficiently
>>> wrong?
>>
>> You are asking if you want the generated code to be efficiently wrong 
>> or inefficiently wrong?
> 
> I was asking if it is reasonable to accept as valid a program which
> is wrong, and make it optimized in its wrong behavior.
> 

Yes, it is.  That is perhaps unfortunate from the programmers' 
viewpoint, but "garbage in, garbage out" is unavoidable.

> What I could not grasp is the difficulty of the job.
> To quote your own words:
> 
>  > Sometimes that means things can appear simple and obvious to the user,
>  > but would require unwarranted effort to implement in the compiler."
> 
>> You can also make use of run-time sanitizers that are ideal for 
>> catching this sort of thing (albeit with an inevitable speed overhead).
>>
>> <https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html>
> 
> Yes, I'm aware of this instruments, but I'm not very knowledgeable about
> it. I'd like to learn more, and I'll need to spend time doing so.
> 

The tools here can be useful.  Of course it is best when you can find 
bugs earlier, at the static analysis stage (I am a big fan of lots of 
compiler warnings), but the "-fsanatize" options are the next step for a 
lot of development.  They are of limited value in my own work (small 
embedded systems - there's often no console for log messages, and much 
less possibility of "hardware accelerated" error detection such as 
creative use of a processor's MMU), but for PC programming they can be a 
great help.

> 
> Thanks!
> 

It's been a good thread - on-topic, interesting discussion, people have 
got a better understanding of a few things, there's an opportunity to 
contribute to better C development tools, and no flames.  I look forward 
to your next question!

[toc] | [prev] | [next] | [standalone]

#396107

From	highcrew <high.crew3868@fastmail.com>
Date	2026-01-03 14:42 +0100
Message-ID	<10jb6d3$181a4$1@dont-email.me>
In reply to	#396105

On 1/3/26 1:42 PM, David Brown wrote:
>> Yes, I'm aware of this instruments, but I'm not very knowledgeable about
>> it. I'd like to learn more, and I'll need to spend time doing so.
>>
> 
> The tools here can be useful.  Of course it is best when you can find 
> bugs earlier, at the static analysis stage (I am a big fan of lots of 
> compiler warnings), but the "-fsanatize" options are the next step for a 
> lot of development.  They are of limited value in my own work (small 
> embedded systems - there's often no console for log messages, and much 
> less possibility of "hardware accelerated" error detection such as 
> creative use of a processor's MMU), but for PC programming they can be a 
> great help.

Agreed.

I happen to work with embedded systems as well, and while I came late to
the party (all the possible checks are already employed by colleagues
who came before me. They took the fun part!), I can tell the value of
sanitizers even if the code will later run on embedded systems.
That's why I say I'd like to learn more: I'm merely a user of it.

Simulations use that code. Then the same code is compiled for the target
platform.

On the light of what I learned on this thread, the value of such testing
is not just mere "let's see if it crashes", but effectively bound to UB!
Or to the attempt to rule out the existing of UB, I should rather say.

Sanitizer to the rescue. Assuming UB is not in the code, we saddle the 
(cross)compiler of the correctness of the output.

Then - I'm reasoning as I write - the devil is in the details.
Let's say that the compiler is unable to catch the issues, and so are
the sanitizers. Then the UB-tainted source code goes to the target.
Assuming the cross compiler is unable to catch it either, we have
a garbage-in-garbage-out situation, affecting the product.

Following this thoughts, I started to wonder: the code I reported in
the beginning of the thread, built with -O2, is effectively coping with
UB by replacing the function with the equivalent of `return 1`.
What if I build it with -O2 and -fsanitize=address?
Will the instrumentation be able to catch it, given that there's nothing
inherently bad around a `return 1` (minus the fact that it's not what 
the developer intended?).

   $ cat x.c
   int table[4] = {0};
   int exists_in_table(int v)
   {
       // return true in one of the first 4 iterations
       // or UB due to out-of-bounds access
       for (int i = 0; i <= 4; i++) {
           if (table[i] == v) return 1;
       }
       return 0;
   }
   $ gcc -c -O2 x.c
   $ objdump --disassemble=exists_in_table x.o

   x.o:     file format elf64-x86-64

   Disassembly of section .text:

   0000000000000000 <exists_in_table>:
      0:   b8 01 00 00 00          mov    $0x1,%eax
      5:   c3                      ret

OK, this is the bad guy. ...now let's sanitize it.

   $ gcc -c -fsanitize=address -O2 x.c
   $ objdump --disassemble=exists_in_table x.o

   x.o:     file format elf64-x86-64

   Disassembly of section .text:

   0000000000000000 <exists_in_table>:
      0:   48 8d 05 00 00 00 00    lea    0x0(%rip),%rax        # 7 
<exists_in_table+0x7>
      7:   48 8d 70 14             lea    0x14(%rax),%rsi
      b:   48 89 c2                mov    %rax,%rdx
      e:   48 c1 ea 03             shr    $0x3,%rdx
     12:   0f b6 8a 00 80 ff 7f    movzbl 0x7fff8000(%rdx),%ecx
     19:   48 89 c2                mov    %rax,%rdx
     1c:   83 e2 07                and    $0x7,%edx
     1f:   83 c2 03                add    $0x3,%edx
     22:   38 ca                   cmp    %cl,%dl
     24:   7c 04                   jl     2a <exists_in_table+0x2a>
     26:   84 c9                   test   %cl,%cl
     28:   75 1c                   jne    46 <exists_in_table+0x46>
     2a:   39 38                   cmp    %edi,(%rax)
     2c:   74 12                   je     40 <exists_in_table+0x40>
     2e:   48 83 c0 04             add    $0x4,%rax
     32:   48 39 f0                cmp    %rsi,%rax
     35:   75 d4                   jne    b <exists_in_table+0xb>
     37:   31 c0                   xor    %eax,%eax
     39:   c3                      ret
     3a:   66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)
     40:   b8 01 00 00 00          mov    $0x1,%eax
     45:   c3                      ret
     46:   48 83 ec 08             sub    $0x8,%rsp
     4a:   48 89 c7                mov    %rax,%rdi
     4d:   e8 00 00 00 00          call   52 <__odr_asan.table+0x12>

   Disassembly of section .text.exit:

   Disassembly of section .text.startup:

Well, what do you know? -fsanitize=address seems to interfere with
optimizations, at least on my system. Link it, run it, and I get a nice
segfault.

Now the circle is closed!

>> Thanks!
>>
> 
> It's been a good thread - on-topic, interesting discussion, people have 
> got a better understanding of a few things, there's an opportunity to 
> contribute to better C development tools, and no flames.  I look forward 
> to your next question!

Thanks. I'm new here, and the community seems a good one! Happy to
contribute.

[Here I'm tempted to go OT with babbling about how nice it would be that
usenet wasn't so underground, but I suspect that is probably what makes
it good. In the small barrel, there is the good wine]

-- 
High Crew

[toc] | [prev] | [next] | [standalone]

#396113

From	David Brown <david.brown@hesbynett.no>
Date	2026-01-03 17:51 +0100
Message-ID	<10jbhds$1chd6$1@dont-email.me>
In reply to	#396107

On 03/01/2026 14:42, highcrew wrote:
> On 1/3/26 1:42 PM, David Brown wrote:

[Be careful snipping attributions.  Make sure you have enough left for 
all levels of quotation.  The following paragraph was written by you, 
not by me.]

>>> Yes, I'm aware of this instruments, but I'm not very knowledgeable about
>>> it. I'd like to learn more, and I'll need to spend time doing so.
>>>
>>
>> The tools here can be useful.  Of course it is best when you can find 
>> bugs earlier, at the static analysis stage (I am a big fan of lots of 
>> compiler warnings), but the "-fsanatize" options are the next step for 
>> a lot of development.  They are of limited value in my own work (small 
>> embedded systems - there's often no console for log messages, and much 
>> less possibility of "hardware accelerated" error detection such as 
>> creative use of a processor's MMU), but for PC programming they can be 
>> a great help.
> 
> Agreed.
> 
> I happen to work with embedded systems as well, and while I came late to
> the party (all the possible checks are already employed by colleagues
> who came before me. They took the fun part!), I can tell the value of
> sanitizers even if the code will later run on embedded systems.
> That's why I say I'd like to learn more: I'm merely a user of it.
> 
<snip>
> 
> Following this thoughts, I started to wonder: the code I reported in
> the beginning of the thread, built with -O2, is effectively coping with
> UB by replacing the function with the equivalent of `return 1`.
> What if I build it with -O2 and -fsanitize=address?
> Will the instrumentation be able to catch it, given that there's nothing
> inherently bad around a `return 1` (minus the fact that it's not what 
> the developer intended?).
> 
<snip>
> 
> Well, what do you know? -fsanitize=address seems to interfere with
> optimizations, at least on my system. Link it, run it, and I get a nice
> segfault.
> 
> Now the circle is closed!
> 

The sanitizers effectively inject code into your source, before any 
optimisations are applied.  You can imagine your code being transformed 
into something like :

   int table[4] = {0};
   int exists_in_table(int v)
   {
       // return true in one of the first 4 iterations
       // or UB due to out-of-bounds access
       for (int i = 0; i <= 4; i++) {
// Start of sanitizer code
           if (i < 0 || i > 3) halt_with_sanitizer_message();
// End of sanitizer code
           if (table[i] == v) return 1;
       }
       return 0;
   }

Then optimisations are applied as normal.

I can strongly recommend <https://godbolt.org> as the tool of choice for 
investigating code generation.  It only works well with small code 
sections, but it gives you very clear generated code, and lets you try 
it with hundreds of different compilers and compiler versions.  It's far 
nicer than doing objdump's or using -Wa,ahsdl flags to generate listing.

[toc] | [prev] | [next] | [standalone]

#396126

From	highcrew <high.crew3868@fastmail.com>
Date	2026-01-04 00:20 +0100
Message-ID	<10jc876$1j15f$3@dont-email.me>
In reply to	#396113

On 1/3/26 5:51 PM, David Brown wrote:
> [Be careful snipping attributions.  Make sure you have enough left for 
> all levels of quotation.  The following paragraph was written by you, 
> not by me.]

I see. I apologize with the crowd, I think I did that a few times.
And sorry for the apologies driven spam too.

-- 
High Crew

[toc] | [prev] | [next] | [standalone]

Page 1 of 6 [1] 2 3 4 5 6 Next page →

csiph-web

On Undefined Behavior

Contents

#396062 — On Undefined Behavior

#396063

#396065

#396095

#396115

#396142

#396148 — Re: On Undefined Behaviour

#396250 — Re: On Undefined Behaviour

#396150

#396153

#396064

#396067

#396078

#396104

#396070

#396079

#396105

#396107

#396113

#396126