Hacker News new | past | comments | ask | show | jobs | submit login

I agree with most of your points, but...

> Even if the generated code is clean today regarding UB, you cannot ensure that a new C compiler version won't be introducing such issues.

This is not correct. Undefined behaviour is specified in the standard, and a good compiler-to-C will always generate UB-free code.




The standard specifies all known cases, the list is not exhaustive from all possible C implementations.


I am sorry but I don't understand... The standard specifies what is UB, and the implementations must behave accordingly to be standard-compliant.

If your code avoids UB behavior as specified by the standard it will run in the same way when compiled with any standard-compliant compiler.


Compiler optimization is a tricky business, where every vendor does all they can to beat the benchmarks game.

What gets documented on the standard is what compiler vendors that bother to seat at ANSI C meetings agree to document as such.

By no means does the standard forbid compiler vendors to take advantage of situations not yet documented as such.

Eventually new cases of UB might get added to the standard.

The current set of about 200 scenarios of UB in C11 weren't all there in C89.

Another example, is that you can have code that is perfectly valid, UB free, but thanks to PGO and code re-writting rules on the optimizer stage, gets rewritten with UB side effects at a later stage in the optimizer pipeline.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: