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)