Hacker News Reader

Comment by mpweiher | Hacker News Reader

> No, UB has always been just undefined

This turns out not to be the case.

There actually is text in the current standard as to what acceptable behavior is when encountering undefined behavior.

This was turned into a "note" in later versions of the standard, but initially it was just as much a normative part of the standard as everything else.

The text is still there.

Compiler writers want to exploit UB, hence they say that this text effectively doesn't exist.

https://blog.metaobject.com/2018/07/a-one-word-change-to-c-s...

View on HN

Compilers don't claim that part of the standart doesn't exist, they just go eith option 1: Ignoring the situation. E.g. if one branch of an if-statement is UB, compilers ignore that that branch can happen and only need to compile the branch they know exists.

No, that's not ignoring the situation. Ignoring the situation is compiling the code and performing whatever operation happens, for example an out of bounds access.

What's the behavior of this piece of code according to the spec? You can choose any C/C++ spec:

   void f() {
      char x[100];
      gets(x);
   }

The key here is the meaning of "ignoring" in "ignoring the situation completely with unpredictable results".

Most programmers (and pretty much all compiler writers) interpret it as meaning that the compiler can assume it can't happen (ignore the possibility) and translate accordingly.

Some, like mpweiher interpret it as meaning that the compiler must implement a trivial (but somehow unspecified) translation to the underlying hardware and let the behavior be what the hardware provides.

edit: We went through this many many times.

This craziness (a belief that if you don't specify what something means it must have some "obvious" behaviour that is coincidentally always whatever the programmer wanted) is endemic in C and C++ communities.

Right now, notionally serious people are making the case that C++ should enshrine the "bag-of-bits" model of pointers which is exactly this sort of stupidity. At first it looks like they want pointers are addresses which is kinda dumb but whatever, and you keep reading and they're like aha, also I should be able to dereference my bag-of-bits and have that work too... Full blown Provenance Via Integers, expect to spend the next forty years trying to specify how any of the optimisations you rely on can survive the resulting tangle, say hi to anybody who wanted Consume ordering and is still waiting.

> This craziness (a belief that if you don't specify what something means it must have some "obvious" behaviour that is coincidentally always whatever the programmer wanted) is endemic in C and C++ communities.

That belief is endemic because that is the way things actually worked for many years! Compilers used to give us the obvious behavior, because they weren't smart enough to outfox us by doing anything else, because the CPUs we used were not fast enough to let them do the kinds of comprehensive optimization analyses which are now routine.

No. The reality is that every new generation of programmers is completely comfortable with optimizations that existed before it started programming and surprised by optimizations added after that. Today we take for granted SSA, extensive interprocedural optimizations, value-range propagation and LTO. Before that was aggressive inlining and SRA; before that was smart register allocation and stack optimizations. Even before that it was instruction scheduling.

Each one of these optimizations have broken someone's code.

The idea that "undefined behavior can't happen" is ludicrous, because it happens all the time. The idea that most programmers also believe this nonsense is entirely unsupported.

It is very popular in a small range of very influential companies.

> Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution ...

As much as I'm not a fan of the status quo, the argument that changing "Possible" back to "Permissible" isn't particularly solid; the rest of the paragraph makes it clear it's not an exhaustive list of behaviours, merely examples from a "range".

Yes, I agree that there are better solutions, this one is just minimal.

The "range" clearly indicates that you can do something that's semantically in-between the options provided.

What current compilers do is nowhere near that range.

Reply on news.ycombinator.com