[lmm]

> a given C compiler + platform will behave completetly deterministically and you can test the output and see what it does, regardless of UB or not.

Sure[1], but that doesn't mean it's safe to publish that C code - the next version of that same compiler on that same platform might do something very different. With machine code (especially x86, with its very friendly memory model) that's unlikely.

(There are cases like unused instructions becoming used in never revisions of a processor - but you wouldn't be using those unused instructions in the first place. Whereas it's extremely common to have C code that looks like it's doing something useful, and is doing that useful thing when compiled with a particular compiler, but is nevertheless undefined behaviour that will do something different in a future version)

[1] Build nondeterminism does exist, but it's not my main concern

[baq]

CPUs get microcode updates all the time, too. Nothing is safe from bitrot unless you’re dedicated to 100% reproducible builds and build on the exact same box you’re running on. (…I’m not, for the record - but the more, the merrier.)

[lmm]

> CPUs get microcode updates all the time, too.

To fix bugs, sure. They don't generally get updates that contain new optimizations that radically break existing machine code, justifying this by saying that the existing code violated some spec.

[carlmr]

>To fix bugs, sure.

Maybe your program worked due to the bug they fixed.

[lmm]

Extremely unlikely. CPU bugs generally halt the CPU or fail to write the result or something like that. The Pentium FDIV bug where it would give a plausible but wrong result was a once in a lifetime thing.

[baq]

Spectre and Meltdown exploits stopped working, too. Some of them on some CPUs, anyway.

[lmm]

Sure. But those were obviously exploits from the start. You wouldn't write code like that accidentally.

[ryao]

Do a web search for rdrand and systemd.

[lmm]

> Do a web search for rdrand and systemd.

RDRAND always returning all-FF is exactly the kind of thing that's an obvious bug, not a plausible-but-wrong result.

[uecker]

It is not terribly hard to generate C code that does not use undefined behavior.

[lmm]

Maybe. But when carefully investigated, the overwhelming majority of C code does in fact use undefined behaviour, and there is no practical way to verify that any given code doesn't.

[uecker]

It is easy to create code where this can be verified. It is difficult to verify for arbitrary code.