From: already5chosen@yahoo.com   
      
   On Fri, 2 Jan 2026 22:56:55 -0000 (UTC)   
   Kaz Kylheku <046-301-5902@kylheku.com> wrote:   
      
   > On 2026-01-01, Michael S  wrote:   
   > > 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!   
   > >>   
   > >   
   > > IMHO, for compiler that eliminated all comparisons (I assume that   
   > > it was gcc -O2/-O3) an absence of warning is a bug.   
   >   
   > A bug against which requirement, articulated where?   
   >   
   > > And it has nothing to do with C standard and what considered UB by   
   > > the standard and what not.   
   >   
   > It has everything to do with it, unfortunately. It literally has   
   > nothing to do with anything else, in fact.   
   >   
   > That function either finds a match in the four array elements and   
   > returns 1, or else its behavior is undefined.   
   >   
   > Therefore there is no situation under which it is /required/ to return   
   > anything other than 1.   
   >   
   > You literally cannot write a test case which tests for the "return 0",   
   > such that the test case has well-defined behavior.   
   >   
   > All well-defined test cases can only test for 1 being returned.   
   >   
   > And that is satisfied by machine code which unconditionally returns 1.   
   >   
   > There is no requirement anywhere that the function requires a   
   > diagnostic; not in ISO C and not in any GCC documentation.   
   >   
   > Therefore your bug report would have to be not about the compiler   
   > behavior but about the lack of the requirement.   
   >   
   > This is a difficult problem: writing the requirement /in a good way/   
   > that covers many cases is not easy, and that's before you implement   
   > anything in the compiler.   
   >   
      
   The text above is an example of languagelowyerish speak. I don't like   
   it.   
      
   gcc maintainer would want to fix it, because they actually care about   
   quality of implementation.   
   Now, being in majority not atypical representative of males of great   
   ape species, the care even more about always feeling right, having last   
   word, etc...   
   Which means that the process of convincing the to make a fix requires   
   wisdom.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)