From: wyniijj5@gmail.com
On Fri, 2026-01-09 at 15:54 +0200, 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.
It is UB, what the implement is irrevant.
The for loop above is equivalent to:
for (int i = 0; i <= 3; i++) {
if (table[i] == v) return 1;
}
if(table[i]==v) { // implement defined
return 1;
}
// implement defined
So, always returning 1 is correct compilation (no way exists_in_table(v) will
return non-1).
> > 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!
> >
>
> Personally, I am not shocked by gcc behavior in this case. May be,
> saddened, but not shocked.
> I am shocked by slightly modified variant of it.
>
> struct {
> int table[4];
> int other_table[4];
> } bar;
>
> int exists_in_table(int v)
> {
> for (int i = 0; i <= 4; i++) {
> if (bar.table[i] == v)
> return 1;
> }
> return 0;
> }
>
> An original variant is unlikely to be present in the code bases that I
> care about professionally. But something akin to modified variant could
> be present.
> Godbolt shows that this behaviour was first introduced in gcc5. It was
> backported to gcc4 series in gcc 4.8
>
> One of my suspect code bases currently at gcc 4.7. I was considering
> moving to 5.3. In lights of that example, I likely am not going to
> do it.
> Unless there is a magic flag that disables this optimization.
>
I am also shocked many seemingly missed.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
