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: Fri, 09 Jan 2026 01:42:53 -0800 Organization: A noiseless patient Spider Lines: 87 Message-ID: <86ms2nm89u.fsf@linuxsc.com> References: <10j6qdt$3q9n4$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Fri, 09 Jan 2026 09:43:05 +0000 (UTC) Injection-Info: dont-email.me; posting-host="f91fed21d6d70b765bc081afc1b51c1a"; logging-data="2392268"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/d8SViSCYdrkuuhrHXuPGO8pkNyUVSRbs=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:8be0oO6mnBN0drSEczERqklXHxo= sha1:RPe0OQDDmaC2RbH+kj0vdGy+Z5w= Xref: csiph.com comp.lang.c:396318 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. After observing that, I think the right question is something like "Given that compilers act in these surprising ways, how should I protect my code so that it doesn't fall prey to the death-by-UB syndrome, or what can I do to diagnose a possibly death-by-UB situation when a strange bug crops up?" I don't pretend to have good answers to these questions. The best advice I can give (besides seeking help from others with more experience) is to be persistent, and to realize that the skills needed for combating a death-by-UB syndrome are rather different from the skills needed for regular programming. I have been in the situation of being made responsible for finding and correcting a death-by-UB kind of symptom, and what's worse in programming environment where I didn't have a great deal of familiarity or experience. Despite those drawbacks the bug got diagnosed and fixed, and I attribute that result mostly to tenacity and by being willing to consider unusual or unfamiliar points of view.