Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: On Undefined Behavior Date: Sun, 11 Jan 2026 11:48:08 -0800 Organization: A noiseless patient Spider Lines: 85 Message-ID: <868qe4lymf.fsf@linuxsc.com> References: <10j6qdt$3q9n4$1@dont-email.me> <86ms2nm89u.fsf@linuxsc.com> <20260109143647.0000372d@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Sun, 11 Jan 2026 19:48:13 +0000 (UTC) Injection-Info: dont-email.me; posting-host="af31aae2f202a5674f65c79be352c26d"; logging-data="172910"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+mSPcx/1Aui4kPDi89cXTE6fZA4qx3vw8=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:7A0iHGgdgyGdf1yUII9Q117B4tU= sha1:RDD7kjx0qpJwZ2+f0YJEkx8p37U= Xref: csiph.com comp.lang.c:396347 Michael S writes: > On Fri, 09 Jan 2026 01:42:53 -0800 > Tim Rentsch wrote: > >> highcrew writes: >> >>> 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! >> >> The important thing to realize is that the fundamental issue here >> is not a technical question but a social question. In effect what >> you are asking is "why doesn't gcc (or clang, or whatever) do what >> I want or expect?". The answer is different people want or expect >> different things. For some people the behavior described is >> egregiously wrong and must be corrected immediately. For other >> people the compiler is acting just as they think it should, >> nothing to see here, just fix the code and move on to the next >> bug. Different people have different priorities. > > I have hard time imagining sort of people that would have objections > in case compiler generates the same code as today, but issues > diagnostic. It depends on what the tradeoffs are. For example, given a choice, I would rather have an option to prevent this particular death-by-UB optimization than an option to issue a diagnostic. Having both costs more effort than having just only one.