Everything in C is undefined behavior

Post by gpderetta » Wed, May 20, 2026, 9:27 AM UTC

anilakar wrote: post #27

bestouff wrote: post #8

The problem of UB is not really that it may crash in some architecture. The real problem is that the compiler expects UB code to NOT happen, so if you write UB code anyway the compiler (and especially the optimizer) is allowed to translate that to anything that's convenient for its happy path. And sometimes that "anything" can be really unexpected (like removing big chunks of code).

Removing code paths that the programmer has explicitly laid out in the source code should be made a hard compile error unless the operation has been tagged with an attribute (anyone who wants to add the unsafe keyword to C? ). Another commenter suggested using LLMs, but I disagree. Having clangd emit warning squiggles for unchecked operations (like signed addition) would be a good start.

   enum op_t{ add, mul };
   int exec(op_t op, int a, int b) {
       if(op == add) { return a+b; }
       if(op == mul) { return a\*b; }
   }

   c = exec(add, a,b);

Post by account42 » Wed, May 20, 2026, 9:29 AM UTC

gpderetta wrote: post #43

veltas wrote: post #22

Earlier quoted context omitted.

Notice though "ignoring the situation" thru "documented manner characteristic of the environment". Even though truly you can read this in an uncharitable way, you could also try and understand the intent of this paragraph, and I think reading it for its intents is always the best way to interpret a language standard when the wording is ambiguous or soft, especially if you're writing a compiler. I don't think you coul…

Ex falso quodlibet. Bounding UB would be a nice idea, or at least prohibiting time-traveling UB (and there is an effort in that direction). But properly specifing it is actually hard.

Post by gpderetta » Wed, May 20, 2026, 9:31 AM UTC

talkin wrote: post #108

layer8 wrote: post #89

Earlier quoted context omitted.

The easy cases like you cite are also those that don’t cause problems in practice. I’m not sure that would help all that much, other than to slightly reduce internet criticism.

Fixing easy cases makes the list shorter, so enables more focus on harder cases. And it also signals that you actually do want to improve, just a little bit of boy scout rule goes a long way.

Post by thomashabets2 » Wed, May 20, 2026, 9:32 AM UTC

codeflo wrote: post #124

> The compiler, and really the underlying hardware too, is playing a game of telephone with your UB intentions. The part about hardware is wrong BTW. In all the cases about null pointers and out-of-bounds access and integer overflow and whatnot, the hardware semantics are clearly defined, and the assembler code does exactly what is written. The way modern compilers act on your code makes C less safe than assembler in…

Post by zarzavat » Wed, May 20, 2026, 9:33 AM UTC

account42 wrote: post #151

inkysigma wrote: post #56

Earlier quoted context omitted.

One example along this path as an example is that every function must either terminate or have a side effect. I don't think one has bitten me yet but I could completely see how you accidentally write some kind of infinite loop or recursion and the function gets deleted. Also, bonus points for tail recursion so this bug might only show up with a higher optimization level if during debug nothing hit the infinite loop.

Infinite loop without side effects == program stuck and not responding on user input and not outputting anything. That's not something a useful program will ever want to do.