Hacker News Reader

Comment by Jiro | Hacker News Reader

Are you sure the compiler didn't say "since having a null pointer gives undefined behavior, we can optimize out the part that confirms the address is non-null"?

View on HN

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.

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?

(You almost certainly know this, but I presume the parent doesn't.)

GCC can be passed `-fno-delete-null-pointer-checks` precisely to prevent this. Linux uses it, see e.g. https://lkml.org/lkml/2018/4/4/601 where it's discussed.

Wait, the compiler can do that? I thought only dereferencing a null pointer gives undefined behavior, just checking if a pointer is 0 or not shold be valid?

Yeah based on https://joelaro.wordpress.com/2015/09/30/gcc-optimization-fd... the assumption is that if the pointer was previously dereferenced, it can be assumed to be non-null, and hence all subsequent null-checks can be elided.

Based on https://news.ycombinator.com/item?id=17360772, the case in which this actually makes a difference is an address offset like

   int *n = &param->length

The compiler knows the structure so it can just inline the offset, but the optimizer considers this as being non-null.

You can check if the address is 0, but the value of the nullptr is implementation definied behaviour. You can have a system where the null pointer is 4.

And address 0 isn't too special on a machine level either. Embedded systems have valid data to read and write there.

Yes. This was upwards of 20 years ago on a DEC Alpha, and we were inspecting the compiled build in gdb using the core file from the crash.

Reply on news.ycombinator.com