Hacker News Reader

Comment by protomikron | Hacker News Reader

What is the history of "undefined behavior" [in C compilers and the standard] in general? I suppose originally it was supposed to guide compiler engineers, but we all know that backfired, as many compilers try to exploit undefined behavior to optimize code, but that can be problematic in security sensitive code (e.g. if uninitialized memory is optimized away) - there have been discussions between security engineers, kernel developers and GCC hackers about how to implement/interpret the standard.

Would it be possible to have a standard, where undefined behavior is just a compile error? What would we lose - apart from legacy compatibility?

View on HN

C sucked on 8 and 16 bit home computers, to be fair, all high level systems programming languages had their own set of issues regarding optimal code generation, thus Assembly was the name of the name for ultimate performance.

UB started as means to not kick out computer architectures that would otherwise not be able to be targeted by fully compliant ISO C compilers.

Given that C prefers to be a kind of portable macro assembler than care about security, it was only a matter of time until those escape hatches started to be taken advantage for optimizations.

Same applies to other languages, however since their communities tend to prefer security before ultimate performance, some optimization paths are not considered as that would hurt their safety goals.

In what concerns C, C++ and Objective-C, dropping UB optimizations would mean going back to the 1990's in terms of code quality.

> Would it be possible to have a standard, where undefined behavior is just a compile error?

No [if you're aiming for something in the same vein as C]. Undefined behavior is ultimately an inherently dynamic property--certain values could make a statement execute undefined behavior, and consequently, virtually every statement could potentially cause undefined behavior. Note that this remains true even in languages like Rust: Rust has loads of undefined behavior, but you do have to wrap code in unsafe blocks to potentially cause undefined behavior.

> What would we lose - apart from legacy compatibility?

In particular, it is clear at this point that if you want to permit converting integers to pointers, you will either have to live with undefined behavior (via pointer provenance) or forgo basically all optimization whatsoever.

Would

   int foo(int x, int y) { return x+y; }

compile? After all, this function can be called in a way that causes UB.

I think what OP is saying is that it should compile and not have any UB, because signed integer overflow should be well-defined.

(This is the case in e.g. C#.)

Presumably, that function would be a compiler error like this.

Unless your program can prove, that the function is only ever called with arguments that don't hit UB.

That's pretty much what Rust was created to do.

Like many others before it, hopefully it gets more adoption this time.

Reply on news.ycombinator.com