From: tr.17687@z991.linuxsc.com

Michael S  writes:

> On Fri, 09 Jan 2026 01:42:53 -0800
> Tim Rentsch  wrote:
>
>> highcrew  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.

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)