Hacker News Reader

Comment by flohofwoe | Hacker News Reader

> that value does not have to be address 0, it could be some other address.

That's what the spec says, but are there any computers around anymore where nullptr is not zero? The spec should really go with the times IMHO, old hardware can be supported via platform-specific language extensions.

View on HN

The cleanest way would probably be to get rid of 0 as a null pointer constant, make its use in contexts that expect a pointer illegal and replace it with an explicit keyword. Of course that would break all existing code that uses 0 or (void*)0 instead of NULL, but if you are out to break things anyway you might as well get rid of 40 year old warts.

Ah a new standard! Perfect! Everyone will adopt this as clearly it is better and there’s no reason not to right? … right?

Well it should be backwards compatible if you just use NULL everywhere where it is appropriate, so you wouldn't even have to sprinkle ifdefs all over the place. Code that uses 0 all over the place would probably have to be updated with the help of compiler errors and a static code analyzer.

https://c-faq.com/null/machexamp.html

> Depending on the ``memory model'' in use, 8086-family processors (PC compatibles) may use 16-bit data pointers and 32-bit function pointers, or vice versa.

And it isn't just zero anyway because there's segmentation in play.

>That's what the spec says, but are there any computers around anymore where nullptr is not zero?

Yeah that's absolutely fair. I actually can't think of a single platform, embedded or otherwise, old or new, where the null pointer is not address 0.

The big place where it happens in modern environments are for pointers to members, where 0 is a bad nullptr value because the member at index 0 is legitimately a thing you want to name. MSVC uses -1 for nullptr in such cases.

I've seen a compiler that has an alternative null pointer address, but I couldn't find it again.

Reply on news.ycombinator.com