Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.lang.c > #396571

Re: On Undefined Behavior

Show all headers | View raw

Michael S <already5chosen@yahoo.com> writes:

> On Sun, 11 Jan 2026 11:48:08 -0800
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Fri, 09 Jan 2026 01:42:53 -0800
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> highcrew <high.crew3868@fastmail.com> writes:
>>>>
>>>>> 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!
>>>>
>>>> The important thing to realize is that the fundamental issue here
>>>> is not a technical question but a social question.  In effect what
>>>> you are asking is "why doesn't gcc (or clang, or whatever) do what
>>>> I want or expect?".  The answer is different people want or expect
>>>> different things.  For some people the behavior described is
>>>> egregiously wrong and must be corrected immediately.  For other
>>>> people the compiler is acting just as they think it should,
>>>> nothing to see here, just fix the code and move on to the next
>>>> bug.  Different people have different priorities.
>>>
>>> I have hard time imagining sort of people that would have objections
>>> in case compiler generates the same code as today, but issues
>>> diagnostic.
>>
>> It depends on what the tradeoffs are.  For example, given a
>> choice, I would rather have an option to prevent this particular
>> death-by-UB optimization than an option to issue a diagnostic.
>> Having both costs more effort than having just only one.
>
> Me too.
> But there are limits to what considered negotiable by worshippers of
> nasal demons and what is beyond that.  Warning is negotiable, turning
> off the transformation is most likely beyond.

What other people think on that matter doesn't change
my comment.

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

Thread

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

csiph-web