Hacker News Reader

Comment by tialaramex | Hacker News Reader

> It would be more helpful for the compiler to assume that it does not know what will happen. This is how C actually worked for many years.

If we don't know what will happen that is Undefined Behaviour.

The contradiction you have within yourself is that you know what you want to happen, but that's not what the specification says. If you want specific behaviour you need to specify what it is - not mumble and make a vague wave of the hand about "behavior you know that the target machine will give you" when you've no promise of any such thing. That would come at a cost, and of course you don't want to pay that cost, but that means you can't have what it buys.

View on HN

That is certainly one perspective that one can have. The point here is that the language and its usage precede the specification, and a pedantic, narrow-minded adherence to a certain interpretation of a document which was actually a post-hoc rationalization of existing practice has made the language less useful for certain applications.

The C standard could easily make dereferencing a null pointer implementation-defined behavior.

And even more critical: Signed integer overflow should be implementation defined, and each implementation do something sane (different from assuming it doesn't happen). This would have saved us many security vulnerabilities, and unnecessary program crashes.

If your program is crashing because of an overflow you’re lucky because it’s saving you from a security vulnerability.

> If we don't know what will happen that is Undefined Behaviour.

Implementation-defined behaviour is a thing. Not knowing what will happen is not an accurate description of undefined behaviour. What the compiler does is assume that undefined behaviour doesn’t happen. When it does happen, it results in a contradiction, and logically every sentence is a consequence of a contradiction (see e.g. “Bertrand Russell is the pope”). That produces all those infamous bugs. Because just like every sentence is a consequence of a contradiction, every program state can be a result of UB. This is untenable.

> What the compiler does is assume that undefined behaviour doesn’t happen

That is an incorrect assumption, as it clearly does.

It is also incorrect given the standard text.

> That is an incorrect assumption, as it clearly does.

That’s my entire point. Compiler is free to make incorrect assumptions.

> It is also incorrect given the standard text.

According to C11 standard, section 3.4.3, the standard imposes no requirements on undefined behaviour.

A compiler that makes incorrect assumptions is a bad compiler.

In fact, in the rationale of the original spec., I remember reading that the C standard was expressly designed to be a minimal spec, and that just being compliant with the spec was insufficient for the resulting compiler to be fit for purpose.

And of course the original spec did specify a range of acceptable behaviors, and that language is, in fact, still in the standard. It was just made non-binding. However, it is still there, and pretending it is not seems disingenuous at best.

> A compiler that makes incorrect assumptions is a bad compiler.

I agree, but that includes GCC and Clang. ¯\_(ツ)_/¯

Yep. The problem when you rely on free software is that you are not a customer.

Reply on news.ycombinator.com