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

1) Challenges in understanding undefined behavior are exactly why tools like ubsan[1] exist. In a way they help /everyone/ understand when 'undefined' constructs are encountered, and having this emitted by the compilers responsible for translating your source code into binary code is the ideal place.

2) Compilers leveraging undefined behavior knowledge get a lot of hate for breaking this implicit contract defining what they "should" do as expected by programmers. Unfortunately these feelings are rather misguided, compilers are just doing what they can to produce the best code for you using the explicit contract that exists: the language specification(s). Are these specifications perfect? No, but they're what we have. If someone were to define a new language that actually captures the assumptions "real" programmers "expect" when they write code then compilers could choose to support it (and probably would!) and everyone would be happier. Until then this is a big case of "how come you're not doing that thing you never said you'd do and no one is willing to define properly?" which is a bit silly. Imagine you're a compiler developer: what assumptions CAN you make to satisfy everyone? In short, compiler developers aren't your enemy, they're just doing everything they can to produce the best code they can for you.

2a) Use of -f* is in a way used to define that a special variant of a language is desired, for example -fwrapv builds the code using an unnamed variant of C where signed integer overflow is well-defined.

[1] http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html



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

Search: