From: already5chosen@yahoo.com   
      
   On Thu, 1 Jan 2026 22:54:05 +0100   
   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.   
   >   
   > 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!   
   >   
      
   Personally, I am not shocked by gcc behavior in this case. May be,   
   saddened, but not shocked.   
   I am shocked by slightly modified variant of it.   
      
   struct {   
     int table[4];   
     int other_table[4];   
   } bar;   
      
   int exists_in_table(int v)   
   {   
      for (int i = 0; i <= 4; i++) {   
        if (bar.table[i] == v)   
          return 1;   
      }   
      return 0;   
   }   
      
   An original variant is unlikely to be present in the code bases that I   
   care about professionally. But something akin to modified variant could   
   be present.   
   Godbolt shows that this behaviour was first introduced in gcc5. It was   
   backported to gcc4 series in gcc 4.8   
      
   One of my suspect code bases currently at gcc 4.7. I was considering   
   moving to 5.3. In lights of that example, I likely am not going to   
   do it.   
   Unless there is a magic flag that disables this optimization.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)