Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: