From: 046-301-5902@kylheku.com
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.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
