Hacker News new | ask | show | jobs
by logicchop 1260 days ago
This is likely your answer. C++ story. I worked at a large company that had a "no exceptions" policy and a custom operator new. If a new expression failed it would return nullptr instead of throwing. So lots of people wrote "checking" code to make sure the result wasn't nullptr, except that the compiler would always just elide that code since the standard mandates that the result cannot be nullptr. Many weird crashes ensued.
3 comments

There are non-throwing operator new overloads that can return nullptr, but I'm not sure if those are a relatively recent development. Did the non-throwing operator new overloads not exist at the time?
Hard to say. Most of the uses probably predated the custom operator new and so nobody thought about it. Not to mention the places you cannot sneak into to switch to std::nothrow.
Ah, that's fair. Didn't think of code that couldn't be changed.
`new (nothrow)` was in C++98 and in ARM C++ before that.
Ah, I didn't know that. Thanks!
The idea that a compiler should just silently omit anything that it’s pretty sure won’t be needed is one of the most bafflingly daft decisions I’ve ever encountered.

If a supplier sent you out-of-spec parts because they didn’t think your spec was actually important, you’d call them fraudulent, not clever.

> The idea that a compiler should just silently omit anything that it’s pretty sure won’t be needed is one of the most bafflingly daft decisions I’ve ever encountered.

It's not merely "pretty sure" - the language is specifically defined this way. C++ in particular requires as a minimum standard from practitioners a perfect knowledge of the vast, complex language standard. Anything less and you'll write a program which is ill-formed or has undefined behaviour, ie your program is nonsense.

I think the key word here is "silently"; It would be one thing if the compiler informed the developer it was going to skip a statement (and said "if you really want this statement kept in, add a preprocessor directive here")
Redundant NULL checks happen all over the place. So the result of your revised requirement would be a huge pile of useless diagnostics. Whereupon, as with similar diagnostics C++ programmers demand a way to switch them off because they're annoying, then they're back to being annoyed that the compiler didn't do what they expected.
Yeah, that's the problem.
Are there any good tools to see how the compiler is rewriting your code? Almost a compiler coupled with a decompiler to show me the diff of what I wrote and what's happening?