From: high.crew3868@fastmail.com   
      
   On 1/3/26 4:53 PM, Andrey Tarasevich wrote:   
   > On your case undefined behavior happens when `i` reaches 4. Hence the   
   > compiler is free to assume that `i` is guaranteed to never reach 4. This   
   > means that the `if` condition is guaranteed to become true at some lower   
   > value of `i` (i.e. the compiler is free to assume that the calling code   
   > made a promise to never pass a `v` that is not present in `table`). This   
   > immediately means that the function will always return 1.   
      
   OK, I totally have missed that there was a rational justification   
   for `return 1`!  Now I see that `return 1` is actually correct, and   
   I'm quite surprised. Thank you for pointing it out!   
      
   (turns out the compiler is in DENIAL of UB :P)   
      
   Interestingly, if I keep in mind this standpoint, every single   
   UB listed in https://en.cppreference.com/w/c/language/behavior.html   
   starts to make a lot of sense. I can even *foresee* the   
   behavior before reading it on the webpage! Damn, I think   
   something clicked in my head now...   
      
   * Signed overflow? UB *can't happen*, therefore `x + 1 > x` is always   
      true   
      
   * Access out of bounds, ...discussed above.   
      
   * Uninitialized scalar:   
      
      size_t f(int x)   
      {   
          size_t a;   
          if (x) // either x nonzero or UB   
              a = 42;   
          return a;   
      }   
      
      Here we *deny* the variable can be used uninitialized,   
      so the presence of UB implies that x is non-zero.   
      The function definitely returns 42   
      
   * Uninitialized scalar 2:   
      
      _Bool p; // uninitialized local variable   
      if (p) // UB access to uninitialized scalar   
          puts("p is true");   
      if (!p) // UB access to uninitialized scalar   
          puts("p is false");   
      
      This is hard to tell ...Shrödinger boolean?   
      
      According to the webpage the program might print both   
      "p is true" and "p is false". Could it be because   
      the compiler has no choice but take the UB route?   
      
      There's no way to mark UB as not reachable.   
      Fortunately the compiler will usually warn me about   
      uninitialized variables.   
      
   I can see a few bold cases down the line, e.g. "Access to   
   pointer passed to realloc" where I start wondering if   
   I could even predict as a human that a certain pointer   
   passed through realloc.   
      
   I have a horrible question now, but that's for a   
   separate question...   
      
      
   Conclusion: the original UB I've been asking about is   
   not even a bug.  It is the compiler dodging a conditional.   
      
   --   
   High Crew   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)