From: high.crew3868@fastmail.com   
      
   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)