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)