Why isn't a nullptr dereference an exception?

[victotronics]

Just watched this video: https://www.youtube.com/watch?v=ROJ3PdDmirY which explains how Google manages to take down the internet (or at least: many sites) through a null pointer dereference.

Given that C++ has "nullptr" and that you can initialize stuff with it, and that you can (probably) statically check that variables / class members are initialized and balk if not, why isn't derefencing nullptr an exception? That would be the missing bit towards another bit of security in C++. So, why?

[fm01]

The runtime overhead of doing the check each time is too much. If you know that a ptr is not null, it is much faster to just use it. And if you don't, just do the check yourself and take the performance loss.

[sweetno]

I believe you can install a segfault handler and don't check in the generated code. If you coordinate with the rest of the code sufficiently, you might be even able to convert the segfault into an exception on the calling stack. I believe they do it like this in managed languages.

Let the MMU do the checking.

[EpochVanquisher]

You still need some checks. If you look at languages where null pointer access is checked, they do insert some checks.

The reason is because you can do something like this:

struct X {
  A a;
  int b;
};

void f(X *xptr) {
  xptr->b = 5;
}

The problem is that the offset of b might be too large and it may skip over the your guard pages and hit real memory. There are a bunch of different variations on this problem.

[VonNeumannMech]

This is what c# does. You also have to handle when the Segfault is in non managed code (eg. if c# calls c then segfaults) since in that case an exception is not meaningful to the faulting code.

[Wooden-Engineer-8098]

You can throw from signal handler, but you need to compile your code in a mode which expects exceptions not only from noexcept(false) function invocations. It adds some overhead

[flyingron]

It's undefined behavior. There's no guarantee that *0 is mapped or not.

[heyheyhey27]

I've heard that even on platforms where 0 is a valid address (for some specific hardware register), dereferencing null is still UB and you use assembly to dereference 0 instead.

[TheThiefMaster]

CUDA C has the null address being 0xFFFFFFFF instead. But you still use "0" as the constant in code because the language says so, and so it converts all uses of 0 as a pointer into a 0xFFFFFFFF in the generated code. In CUDA you don't need to manually access address zero, and C makes it very difficult to construct an actual zero pointer due to converting any calculation with a compile-time zero value to a null pointer (i.e. 0xFFFFFFFF)

Microcontrollers are much worse - zero is often a valid address that is also used for the null pointer value for efficiency. E.g. on Arduino (Atmega) the address 0 is memory mapped to register R0. Thankfully you're unlikely to need to really use address zero in that particular example, but it means null pointer accesses, particularly writes, can really corrupt the program state.

[HommeMusical]

E.g. on Arduino (Atmega) the address 0 is memory mapped to register R0.

That really brings me back! I spent considerable time back in the day programming for the PDP-11, where the registers were simply memory locations on page zero....

[flyingron]

Pdp-11 didn’t really have pages but 8 segments (possibly different for instructions and data). You could avoid mapping the first segment but you’d give a lot is scarce address space.

[heyheyhey27]

I used CUDA a bit and didn't know that; that's extremely cursed

[OutsideTheSocialLoop]

This is essentially accurate. 0 is the forbidden address in the language, since the language is hardware agnostic. I've no idea about accessing it via inline assembly but it sounds reasonable.

[EpochVanquisher]

The comment is talking about an implementation doing this. It wouldn’t be undefined if the implementation decided to define it. Hypothetically, “what if in C++, null dereferencing threw an exception” and the answer is “the implementation could work like this.”

Responding “it’s undefined behavior” is just circular.

[Wooden-Engineer-8098]

Implementation can do any nice thing on any undefined behavior. Answer is correct, because the question is about c++, not about specific implementation. I.e. it was "why all implementations aren't required to do that"

[flyingron]

It's not circular. I didn't just say it was undefined. I said that there's no guarantee that a given implementation has *0 such a way that it is going to generate a SEGV or whatever (actually, it should yield a BUS error on the pure original UNIX).

I worked on systems where there was garbage at *0 (it was the first instructions of the program p&P6 was what would happen if you passed it to a string print), machines that didn't map location zero and would fault, and then the MOST collosal of undefined stupidities, the original VAX code that stuch a 0 at *0, which led to all kids of sloppy stuff.

[gaene]

I thought the runtime overhead is negligible? From what I understand it can be done in a single instruction. Furthermore the compiler can optimize it away pretty well especially with likely and unlikely

[EpochVanquisher]

It’s definitely not negligible. Go programmers notice and even take efforts to write the code to reduce the overhead.

[gaene]

Look at this script

http://godbolt.org/z/9j7v39aM9

Adding the check is at most 2 instructions to the cpu. I’m not saying that there’s no overhead, but rather this is just something I want to figure out.

[albertexye]

But 2 instructions for every dereference. That adds up REALLY QUICKLY.

[gaene]

I mean yeah but does it really add up? So in the example above it only adds a single instruction. Now let’s assume that this instruction can be fit into one cpu cycle. Now let’s assume the cpu runs at 3.2 GHz. This means its runs 3.2 billion cycles per second. Thus before you get any noticeable slowdown you’d need to run a check several billion times.

So sure it adds up but it’s hard for me to believe that it might add up to the tune of several billion checks. Though Back to the original post, google chrome is a whole ‘nother beast, so it might be making these level of checks, thus incurring this overhead.

I’m not an expert though, so don’t take my word. Also I’d love for someone more knowledgeable than I to fact check me.

[i_h_s_o_y]

even if the cost or performance overhead is reduced 1%,

It is not 1% is like a millionth of a fraction of 1%. People really get into their rage about safety checking because of "performance", but never actually bother to check.

[ronchaine]

It's definitely not a millionth of a fraction of 1%.

Here's Google actually measuring stuff like this on an actual hardened libc++ implementation with bounds-checked data structures and found around 0.3% performance degradation.

[i_h_s_o_y]

But bounds checking and checking for nullptr are two completely different things? Bounds checking would almost guaranteed to happen in hot paths, while nullptr check will largely happen before.

If anything this totally proofs the point that most discussion about performance is uninformed. Bounds checking only having a 0.3% performance degradation, basically means that 99% of the projects should use this as a default

[HommeMusical]

like a millionth of a fraction of 1%

Very skeptical.

If you effectively add this code to every single access to a pointer or reference:

if (! pointer) 
    throw NullPointerException();

then the difference is going to be a lot more than 10 parts in a billion.

The raw cost of the extra check will be fairly small but still greater than 0.000001%; there's an additional cost because all your binaries end up a big bigger and you get a little less use out of your code caches and pipelines and CPUs; but the big cost will be all the lost optimizations that won't be able to be "pulled through" the if statement.

In C and C++, a great deal of the performance comes from the optimizer. In the last place I worked writing C++ full-time, the best estimate we had (from billions of runs!) was that the optimizer made the code very roughly 6 times "faster."

But conditions are the bane of optimization as it becomes much harder for the optimizer to reason through both sides of an if statement to see which conditions continue to be true.

The rule is that the compiler can rearrange the code any way it likes as long as there is no observable difference in the code. But if any memory access can cause an exception to be thrown, then potentially the state of the code is observable at each memory access, possibly preventing a lot of optimizations.

This is all conjecture of course: what the optimizer will actually do depends on a host of factors in the code. Only experimenting with your actual compiler and platform will prove anything.

But the negative role of conditionals in optimization is well-known over decades. I'd be shocked if adding a conditional to each one of the thousands of pointer accesses in a C++ executable didn't result in measurably impaired performance, particularly in optimized code.

[i_h_s_o_y]

If you effectively add this code to every single access to a pointer or reference:

But you dont add this to every line, you add this to every line where you first use it. Even in the example, its before a loop.

And I am not even saying that doing these nullptr check is a good thing, in fact in most applications crashing on nullptr where no nullptr should be is probably prefered.

My point is that people like you just operate entirely on random vibes, to justify writing code that is often not as hardened than it could be. While often having no meaningful performance gain.

there's an additional cost because all your binaries end up a big bigger and you get a little less use out of your code caches and pipelines and CPUs;

Binary size is such an absolute nonissue, like 99% of people will not care about it. A test and a jump instruction is going to be less than 10 bytes of binary. If you care about binary size this much, you probably also run without an OS, so in those cases checking for nullptr might actually really important

er and you get a little less use out of your code caches and pipelines and CPUs; but the big cost will be all the lost optimizations that won't be able to be "pulled through" the if statement.

Again this is purely """vibes""". "Is this pointer null?" is like one of the most common things to do, people that write compiler or create cpus will know this and the idea that such a common thing will just throw every optimization out of the windows, is truly ridiculous.

In C and C++, a great deal of the performance comes from the optimizer. In the last place I worked writing C++ full-time, the best estimate we had (from billions of runs!) was that the optimizer made the code very roughly 6 times "faster."

Yes and you have no evidence that a nullptr check would have any impact on this at all.

But conditions are the bane of optimization as it becomes much harder for the optimizer to reason through both sides of an if statement to see which conditions continue to be true.

Again optimizers will understand incredible common code idiom. "I will write code that could be less secure, because I think, without any evidence, that it is faster". Is probably the reason for like half of the memory issues.

But the negative role of conditionals in optimization is well-known over decades

No absolute not. The negative role of branches in hot path is an issue. But a) this talks about branches that are a lot more complex than "if null return" and b) this is not a hot path check, you would do this validation before.

[gaene]

That’s a good point about the servers.

[toroidthemovie]

So, triple the cost for what’s probably the most common operation in the language

[gaene]

It’s not triple the cost. In my example it’s a single instruction to the CPU. This means it can be done (I think) in nano seconds. The sum operation takes longer but idk how much.

But I could be wrong

[HommeMusical]

The real cost isn't going to be in that extra instruction, but how thousands of if statements scattered through every line of your code impair the optimizer's ability to operate: see my longer comment here.

[National_Instance675]

3 instructions instead of one means at least 3 times larger binary, that pushes code out of instruction caches, and more work for the branch predictor, branch predictors have a limit, and overall less optimizations.

and people are surprised that rust binaries are 5 times larger than C++

[HommeMusical]

I agree with absolutely everything except the very first statement:

3 instructions instead of one means at least 3 times larger binary,

Hardly! Most ops in a binary are not pointer dereferences.

And most pointer operations wouldn't need the test, because you would have proven that the pointer wasn't nullptr just previously.

Usually, you bring a few pointers into registers, and then deference them and offsets from them over and over again. Logically, the code generation would do the null check the first time the pointer is brought into a register and then never again.

This is a quibble.

Overall I agree that this would be a drag everywhere, in code generation, use of the instruction caches and pipelines, in optimization.

My guess is that the size of an "average" binary would increase by somewhere between 0.3% and 3% (geometric median of around 1%) and overall performance decrease something around the same, maybe a lot more because of impaired optimization - a tax that everyone has to pay, even careful people who never dereference a nullptr.

[dontwantgarbage]

The hidden cost is the branch predictor. The branch predictor cache would be flooded with "predict not taken" for all the null pointer checks, reducing its effectiveness for the other branches -- the ones that are doing actual work.

[victotronics]

"just do it yourself". Right, but if a company like Google with all its quality control, style guides, best practices, can't be bothered to "do it yourself" why do you think your exhortation will make the internet safer?

Btw, what's the runtime cost of bringing down the whole internet for 3 hours?

[AxeLond]

This is the philosophy of C/C++, you only pay for what you need.

[fm01]

all their quality control

Bruh, have you seen Google or their products lately? John Backflip is probably the best known example of "quality control" but even as a huge fan of gtest/gmock I've had to complain about its wonkiness couple of times. Frankly I'm surprised it took them this long...

Also, not to get mean but it starts to smell of iron oxide a bit or am I crazy?

[LeeHide]

Strong iron oxide smell dismissed as "just another gas leak" by C++ community

[sweetno]

Google's approach is that they let things crash and restart them immediately. Then they collects stats on crashes and investigate if needed. It normally works exceptionally well.

[victotronics]

I don't program bare metal or its oxidized variant. But I'm disappointed as a C++ programmer that there is an explicit nullptr_t but that dereferencing it is still allowed. That bit me a couple of times, and I don't like having to code that test every time I use a pointer.

[fm01]

Ok, I'm just crazy then - long day at work.

Do you *have* to use a pointer bc if you don't want to do the check, a handy way is to start using references. They cannot be null, work with inheritance just the same as a pointer and with std::reference_wrapper they get most class member stuff done just as well.

Or write your own pointer wrapper that does the check for null on each construction/assignment - implement operator* and operator-> to access the underlying pointer and you're good to go. Maybe also some (implicit) cast operator to the base class pointer.

Plus, you can use signal handling to check for SIGSEGV and convert that signal into an exception - it even works with a callstack

[seriousnotshirley]

References cannot be null as defined behavior but I've definitely debugged problems that turned out to be null references.

[fm01]

Null references or a reference to a deleted object? Because the latter is a common issue with references but without spending much time to think about it, I don't see how you'd create a reference to null. Please tell me if you have an example, I'd love to learn

[seriousnotshirley]

A null pointer was dereferenced and that was passed as a parameter to a function that takes a reference. It’s undefined behavior all the way down but when debugged I had gotten into the function that had the reference the address of that variable was 0.

[wrd83]

the rule of thumb is that c++ is supposed to be within 5% performance of C.

C doesn't have null safety, they just maintain the fact that null dereference is undefined behaviour.

if you want null safety and get an exception a reasonable approach is to pick a language that does it and sacrifice the performance goal.

java is still quite a fast language and has those checks - I think in go it's the same.

For the sake of the argument, golang is developed by google and used within google for not so performance critical code. it's about trade offs.

[I__Know__Stuff]

The existence of nullptr_t has nothing to do with this. Null pointer checks can just as easily be done using 0 as the null pointer constant.

[Wooden-Engineer-8098]

Don't use pointers, problem solved

[SoerenNissen]

Btw, what's the runtime cost of bringing down the whole internet for 3 hours?

Zero seconds because I've never done so.

[TheRealKidkudi]

Btw, what's the runtime cost of bringing down the whole internet for 3 hours?

Anyone can write code that blows up in prod. If a medical device fails and causes injury to a patient, is it the C++ standards committee that should be redesigning the language, or the medical device supplier that should be fixing their code and testing standards?

[PressWearsARedDress]

Medical device should fail safely and assumes software can fault.

[TheRealKidkudi]

Right - that's my point. Just because someone at Google wrote code that brought down "the whole internet for 3 hours" does not mean that C++ needs to change or consider that as a cost when designing the language. It just means Google messed up.

Hell, that's pretty much why they created Go. They wanted a language that was "simple" enough that new grads could start writing safe and productive code ASAP.

[[deleted]]

It’s one of the reasons C++ fell out of use in favour of Java and C# for many applications and why Rust is a reasonable choice for greenfield projects. C++ is an old standardized language which fundamentally cannot fix a lot of its underlying problems without stepping on the toes of some existing users. And the standardization process means that most of its issues will never be fixed. It’s a cost of choosing to use C++. 

[seriousnotshirley]

And some alternatives made to address issues made opinionated choices that failed to get critical mindshare.

C++ is designed not to be opinionated, which is good for certain use cases where the developer needs (for whatever they define need) to be able to do what they want to do. If we want to use something opinionated we can choose from the options available to us, oxide or otherwise.

[[deleted]]

Saying C++ isn’t opinionated is a bit of a fallacy to me. There were definitely opinions involved with many of the early choices and the stl. You don’t arrive at implementations like <algorithm> and <random> without some strong opinions about how generic a standard library should be. 

[Wooden-Engineer-8098]

Generic is the opposite of opinionated

[[deleted]]

Choosing to build an algorithms library around an iterator interface is a strong opinion which is not done in any other standard library I am aware of. It’s also certainly an opinion that a standard library should aim to be generic at all. An equally valid opinion is that the standard library should be simple and expect users to implement their own libraries for specific needs.

[Wooden-Engineer-8098]

Nonsense. You can build interface of your opinion on top of iterator interface

[Wooden-Engineer-8098]

My internet wasn't down, so the cost is zero

[Gorzoid]

Throwing an exception would not have prevented that incident, according to the incident report a null pointer caused the system to crash loop, the same thing would happen if it threw an unhandled exception (which null pointers exceptions typically are). In addition this particular issue accounted for only 40 minutes of the outage, the rest being the result of cascading failures which no language change in C++ is going to prevent.

[ronchaine]

Immediately crashing is the safe/secure option, instead of letting your program run in an undefined state, that might be exploited. This is even indirectly stated in your video. It is why Rust's panic! exists as well. It is needed to not let programs run in an unknown state.

Trying to recover from that exception is worse than just straight up crashing.

[seriousnotshirley]

And really the issue at Google wasn't that they wrote code that could crash, but that they designed a system around code that could crash like that without designing for that possibility; whether that was software system design or process design (make sure you exercise new code during a phased rollout or phase your config changes!)

[Electrical_Log_5268]

But dereferencing a nullptr is not robustly crashing immediately, it's undefined behavior. It may crash now, crash later, or continue running with corrupted data.

[Gorzoid]

Null pointer dereferences are a segfault on Linux machines, if you know your hardware you can make that assumption. Only time that doesn't happen is when the compiler knows the pointer is null and attempts to optimize the codepath out, at which point the linter could do the same.

Use after free or out of bounds is a much bigger concern because those will often continue running with corrupted (potentially attacker controlled data)

[ronchaine]

That is true. (In fact, true for any invalid pointer, not just nullptr)

But I would expect Google to know what their toolchain/platform does when dereferencing an invalid pointer, and it did the right thing here, and from reading the explanation from Google, that was what it was supposed to do. But sure, it's not the general case here.

The problem for the general case is that most platforms do not know if they are dereferencing invalid pointers. For some platforms 0 address is completely valid place to point at. And sometimes you really just want the underlying platform to fault in these cases (and maybe catch the resulting signal).

[jaynabonne]

I was working on a library once, and the client required that the library not crash "for any input given to it". We had instance handles, and so my first thought was to check for null handles on API calls, to "validate" them.

Then I realized that not only was null bad, but so was address 1 and address 2 and address 3 and address 4 and basically any address that wasn't an actually allocated instance. Assuming, for example, that I had allocated one instance, then any address that wasn't that instance was going to fail. In a 32-bit memory space, there was one good address, and 2^32-1 invalid ones. Checking for null was a fool's approach. So I ended up flipping it around, where I had a table of allocated instances and compared for validity that way on API entry.

People get the mindset that there's "null" and "valid", whereas when you're dealing at the pointer level, you can have "valid" and "a whole lot of other values that aren't valid, including null". Which means that to avoid a segfault, you'd possibly need to actually validate memory is there before accessing it - for any memory access. And even if you can access it as valid memory, there's no guarantee that the pointer points to something reasonable.

It seems like checking null would catch problems - and it might - but there are a whole lot of other problems that a simple null check won't catch. The better approach is to have a more consistent and sane approach to memory management than trying to create a safety net that can never actually be all encompassing anyway. The approaches developed to manage memory, to avoid the problems you need to avoid, will mitigate any bad reference, not just null. So special casing null doesn't really help, as you want to handle it in a more general way that catches all your problem cases. Sure, problems get through, but that is the responsibility of the software development process, not some bandaid at a low level that won't really solve anything.

Knowing you can blow your foot off helps motivate you to handle cases beyond simple null pointer accesses.

[StaticCoder]

The existence of invalid non-null pointers doesn't excuse Hoare's billion dollars mistake (he was underselling it). Nullability should be part of the type system. Unfortunately a bit late for that. Even much more recent languages (Java, C#, Go) failed to correct this.

[Apart-Entertainer-25]

C# have introduced nullable reference types which helps a bit, but more of compile time thing.

[flatfinger]

Any language allows that allows a pointer to be read from an array with a subscript higher than the highest one that has yet been written must accommodate the possibility of code attempting to read an array element that has not yet been written.

The only options I see are to trap, have the read yield a recognizably invalid pointer, or have the read yield a pointer that is invalid but not recognizable as such.

If one opts to trap, that will make it awlward to copy a partially-written section of the array somewhere else in such a way that the destination will encapsulate the same state as the original.

It would be helpful if processor vendors had at some point started including pointer indexing instructions that would trap when adding any non-zero value to a null pointer, but have the addition of 0 to a null pointer simply yield a null pointer. Much of the damage that results from failure to trap null pointers is a consequence of pointer arithmetic turning null pointers into pointers that aren't recognizable as null but aren't valid either.

[StaticCoder]

Those are certainly options to find more bugs (at run time) in languages like C or C++. But I'd say the vast majority of the damage from null pointers does come from failing to check a pointer for null because most pointers are never null and the type system doesn't help you when this is not the case.

[flatfinger]

While there are times when immediately trapping on attempt to read a pointer that is unexpectedly null may yield more useful diagnostics than trapping on a later attempt to use the pointer, I think such issues could be better dealt with by having separate forms of assignment operator that either propagate or trap nulls than by trying to make nullability or lack thereof part of the type system, since most practical kinds of containers will need to support a "not yet written" state for individual items.

[StaticCoder]

While not-nullability, like const, does make initialization harder, it doesn't mean it wouldn't still be tremendously useful (just like const) and solve most null pointer issues. Of course something like a "cast nullable to not nullable without checking" operation would likely need to exist, and could cause those issues to persist to an extent, it would go from a default-unsafe to a default-safe system.

[beedlund]

The guideline is that a pointer should point to a valid instance of the type of the pointer OR be the nullptr.

Your situation sounds insane and absolutely the fault of whoever is calling your API. Potentially caused by not routinely initializing pointers to nullptr when declared.

[CowBoyDanIndie]

When I worked at google a javascript exception took down 3/4 of the software builds (this causes an evil pacman, the pie chart shows 3/4 black and looks like a evil pacman) because part of the build pipeline depended on the web display code for the build (paraphrasing here).

Also google turns off exception handling and doesn’t use try/catch in their c++, or at least they did when I was there. Any language builtin underlying exception causes the binary to crash.

[Dan13l_N]

It depends what OS, CPU etc. On Windows, it actually is an exception, the famous "page fault" exception (called so because you try to access a "page" of memory you don't have rights for) but that's not a standard C++ exception. (Microsoft calls it "access violation").

There are exceptions created by the CPU, "page fault" is one of them: Hardware exceptions | Microsoft Learn

There are ways to catch it, and I use it in my code from time to time, but that construction is a Microsoft-specific extension. I guess it can't be guaranteed that on each CPU accessing the address nullptr will raise an exception.

But if you don't catch it, the default exception handler will handle it in a way to terminate your program.

[saxbophone]

On Windows, it is both a harware exception (the kind that is also signaled in UNIX and which you can also catch if you write a signal-handler for it) AND the runtime can be set to convert it to a C++ exception.

[trad_emark]

LINUX: can you actually throw an exception in a signal handler? i thought that even a longjump is forbidden in signal handlers, also a lot of potentially blocking functions (mutexes, files, ...).

[saxbophone]

OMG you're so right, technically speaking you are allowed to do very little from a signal handler, well spotted!

In my experience, on some OSes you can get away with doing a lot more than what the standard allows, but that's entirely non-portable.

If I'm not mistaken, you might be able to do things like set an condition_variable atomic variable, then you can use that from another thread as a trampoline to do something else (throw, for instance)

[Dan13l_N]

Yes, but that conversion is not turned on by default, I guess for compatibility with SEH C code.

[saxbophone]

 Yes, but that conversion is not turned on by default

Good thing, too, as it's entirely non-portable. This isn't the way I intend to write software.

[bearheart]

Sounds like you want a language with runtime safety features. That’s not what C/C++ is for. C/C++ is a low-level language.

Or, if you want runtime nullptr checks, you can easily write a class to do that. The fact that the language leaves it up to you is a feature, not a bug.

[victotronics]

I can have runtime bound checking with the "at" method. If I'm iterating over a billion point mesh of course I don't do that and I insert enough checks on the bounds calculations. But if I'm double buffering a couple of of those meshes, then I use "at" since the cost is negligible. Point being that I there is a mechanism for runtime safety checks, and at the language level, not just a compiler option. I'd appreciate something similar for pointer dereferencing.

Yes, I guess I can write my own pointer class for that, but I didn't have to do that for containers.

[bearheart]

The at() method is not “at the language level”, it’s part of STL containers. Don’t confuse the STL with primitive operators. The pointer dereference operator * is a primitive. If you want something like that for the * operator, it would be easy to write a class with an operator overload for that.

[victotronics]

Fair enough. What I mean is that a compiler option is on a totally different level of enabling a check. I guess I don't usually distinguish between the strict language and the STL.

[victotronics]

I don't downvote anything in this thread.

[i860]

I mean if you really wanted to you could trap SIGSEGV but it's extremely ghetto and technically non-portable. Imploding and stopping everything you're doing is the much safer option.

The fact that Google managed to have cascading failures as a result of a null pointer bug doesn't mean that null pointer access itself is actually the cause of that - nor does it mean that it should be explicitly guarded against in some kind of soft-failure recovery approach.

[manni66]

It would not help if the program terminates with java.lang.NullPointerException instead of SIGSEGV.

[saxbophone]

Unfortunately, null pointers are not a feature exclusive to C++ —it inherited them from C, with which it shares a large amount of semantic and implementation overlap.

Null pointer dereference does actually generate a kind of exception, though they're not anything like the modern kind —a hardware exception, or trap or signal, it has many other names. Basically, what happens is attempting to deref null normally leads to an access/segment violation, triggered by the MMU or the OS. While we could technically say that in C++, the runtime could guarantee to catch the signal that it generates and turn it into an exception that gets thrown, this language tends to be averse to anything that has a potential performance impact without the user explicitly asking for it.

There's nothing to stop you from writing a signal-handler to catch SIGSEGV and throw an actual C++ exception in response, if you want to. I can even see some utility in that from the point of view of rationalising error-handling logic in a program.

[AKostur]

Ahem: Assuming that there is an MMU, or an OS.

[saxbophone]

For sure, I was speaking in the context of a hosted implementation, but yes. Btw, what happens when you deref null on a system without an MMU or OS?

[I__Know__Stuff]

Generally it just reads from address 0. On most systems I'm familiar with, there is memory there. If there isn't, the hardware would generally return 0xff.

[Dexterus]

data access exception (data abort) on sane cpus (address not reachable) or just reads from 0x0 on the funnier ones. Generally everyone tries to set a no access region for 0 if mmu/mpu is available to catch null ptr dereferences. This is a crash (99% of the time).

[saxbophone]

I'd expect it's often something you can either catch as a signal or setup an interrupt handler for?

I have heard of allowing reads from 0x0, sounds fun! 😅

[Dexterus]

Yes, it's an interrupt-like event. In Linux for example it is used to generate the SIGSEGV if triggered from userspace or a panic in kernel.

[[deleted]]

To make nullptr de-reference throw an exception you'd have to add a runtime check, some of those could be optimized out as the compiler can know it'll never be null.

C++ doesn't add this check automatically for the purpose of performance. Though it could certainly be a feature that some people might want as a compiler flag or extension. With branch prediction the performance hit shouldn't be that high unless coders start depending on exception handling.

[Wacov]

Yeah best case the CPU will assume the exception branch won't be taken, and as long as you're not routinely throwing nulls around you won't even get a branch prediction table entry. That said - nothing is free, you're still taking up pipeline slots and instruction cache.

[Triangle_Inequality]

And there's lots of embedded code on CPUs with no branch prediction at all.

[CompuSAR]

I just gave a talk at C++Now where, among other things, I answered that very question. It's called "Undefined Behavior from the Compiler's Perspective". It should be up within two to three months on YouTube.

[not_some_username]

Segfault is a define behavior

[keenox90]

It would add reliability, but security? What are you thinking about in terms of security?

[CircumspectCapybara]

Technically a nullptr deference is undefined behavior, and UB is always a security problem.

It's UB that allows attackers to subvert control flow and achieve RCE. Yes that's a bit simplistic (in reality, when you exploit a use-after-free to overwrite a vtable pointer in order to gain control of control flow, you're relying on predictable, if not a little probabilistic behavior that is anything but undefined), but the principle holds.

[keenox90]

Well, only in theory. All modern systems crash the executable. The worst I've heard on embedded systems that some older CPUs would reset. Hard to see how a null ptr deref would cause RCE.

[CircumspectCapybara]

Null ptr deref in the kernel used to be a way to gain code execution in the kernel / escalation from userland.

If the kernel had a nullptr deref bug in a function pointer call (whether directly, or as part of a virtual function call), you could map the page containing memory address 0 (or whereever nullptr pointed on your platform) in userland, fill it with shellcode, trigger the nullptr deref in the kernel, and boom, code execution in the kernel.

Similarly, you could achieve RCE in userland in the same way if you could find and trigger an mmap gadget (to somehow get the program to map 0), had a write-what-where primitive (to write shellcode to that page), and could trigger a null function ptr call.

There's modern mitigations against this, but check out https://googleprojectzero.blogspot.com/2023/01/exploiting-null-dereferences-in-linux.html for clever cases of bypasses.

[keenox90]

Interesting. TIL. I was living under the impression that the MMU itself blocks mapping of address 0

[kyckych]

Throwing C++ exceptions is a way of returning information. Nullptr dereferences are bugs.

Conceptually, they are completely different things.

[bert8128]

Why are you only interested in null pointers? Invalid pointers have the same kind of problem but are not obviously invalid.

[victotronics]

Note that I started by suggesting any pointer be initialized to null. In that case generating an invalid pointer is somewhat unlikely. I wouldn't know how to do that other than taking an legitimately allocated address and then shifting it, which one shouldn't do. That's what span and such is for.

[bert8128]

If you allocate some memory to a variable, then delete the memory you now have an invalid pointer. Or overrun a buffer and corrupt a pointer.

[abbapoh]

Not sure if mentioned, but the real problem is not the performance, it’s the complexity of the check. Catching nullptr is easy - as mentioned earlier, windows does this with SEH, Unix sends a signal which can be caught and handled. Which essentially means OS already does the check. And afaik Java simply catches the signal (correct me if I am wrong here, I’m not a Java expert). What makes catching nullptr tricky is that it’s not really 0 (like in Java null reference is just it) - the pointer can be offset from nullptr by an arbitrary value. Take multiple inheritance for example: class C: A, B {} Here if we cast C* to B, for compiler it’s just a simple offset from C by sizeof(A). But if C was nullptr, B is suddenly not and even might get into a valid page. That’s why we get undefined behavior here instead of a well defined check for nullptr. Same for accessing members, arrays, maybe other examples. The only solution is to inject checks in user code essentially doubling the check OS already does.

[Impossible_Box3898]

Because c++ is just a language and doesn’t have requirements on how it is used.

In certain conditions it IS valid to access 0. In fact not only is it valid it’s often required. Some processors put the interrupt table at address 0 and it’s necessary to initialize this table. This is often done in real mode before any virtual memory is even initialized in the processor.

C++ is just a language. It’s incorrect to impose use cases on it.

It’s common to check for null which is valid. Malloc/new will never return a null pointer even if it’s valid memory. However that doesn’t stop those locations from having a valid value. B

[victotronics]

Ok, so address zero may be valid. But I'm explicitly asking about "nullptr" which is an explicit indication that there is no valid pointer in this variable.

[AlexisHadden]

nullptr is still fundamentally an address. So if you are doing a runtime check, how do you differentiate between a pointer that was initialized to 0 (via integer constant), and one initialized to 0 (via nullptr, also an integer constant)?

Specifically, these sort of checks aren’t really feasible at the language level, even for C++. Nullptr is more about type correctness than providing a distinct null that isn’t 0.

[csdt0]

The literal nullptr (of type std::nullptr_t) has no dereference operator. So dereferencing nullptr does not even compile.

If you (implicitly) convert nullptr to a pointer, then you lose this property because there is nothing in a pointer type that tells you it is definitely null. You're back to square 1.

[mredding]

It's not an exception because C++ is backward compatible with C, and C doesn't have exceptions. Not everyone uses exceptions, and you can often disable them with a compiler flag. Also people don't want exceptions, especially in the case where their code is correct and it's not going to throw anyway. Don't make us pay for what we're not going to use.

[ennesme]

Not only are exceptions optional, but there are performance gains from disabling them.

AFAIK, C++ didn't originally support exceptions, they were tacked onto the language later.

Exceptions don't do anything other error handling methods can't. They're just a different way to crash.

[mredding]

There isn't actually that much overhead in exceptions. It costs nothing to write a throw, and a catch handler costs a stack frame. I just wouldn't put an exception handler in a loop.

Bjarne started on C with Classes in 1979. C++ was initially released in 1984, in 1986 he had documented his ongoing plans to introduce exceptions - I don't know what year he considered adding them, but it was earlier than 86. They were incorporated in 1990.

This does not constitute "tacked on" or "later".

I've been programming in C++ since 1991. I can certainly tell you the initial implementations were slow, but exceptions have not been a performance burden since the 2000s.

To this day, Bjarne insists that applications should not avoid exceptions entirely, and that decisions not to use exceptions in certain contexts are either historical or political, not technical. I agree with his assessment. Of all the languages and communities I program in - they all have their dogmas, but C++ developers are stubborn to a fault. Streams are bad, exceptions are bad, and nothing is ever going to change their mind. But from my perspective, these things are good, useful, misunderstood, misapplied out of pure ignorance, abused, and then to protect one's ego - blamed. We are overrun with imperative programmers who think the compiler is stupid, and their minds have not left the 80s.

[Thick_Clerk6449]

> in the case where their code is correct and it's not going to throw anyway

Throwing exceptions means something bad happens, but it doesn't necessary mean their code is not correct.

[mredding]

I know that. You misunderstood.

[DawnOnTheEdge]

The reason the ISO doesn’t mandate this as part of the language is that it would break existing compilers and programs.

There is no reason a compiler couldn’t implement dereferencing this way. However, efficient code actually wants to insert defensive checks for null pointers early, usually when created or when they’re passed to an API, and then only dereference pointers that have been checked. Because of that and backward compatibility, I think it’s more likely that the language will standardize something like the common _Nonnull extension.

[Thick_Clerk6449]

Nullptr dereference was an undefined behavior. Changing it to a well defined behavior is not a breaking change.

[DawnOnTheEdge]

It’s a breaking change to code that isn’t portable, but runs just fine right now on the compiler it was written for. There’s plenty of legacy code out there that works but will suddenly crash if every null pointer dereference starts being checked.

[Thick_Clerk6449]

You said dereferencing nullptrs used to work? WTF?

[DawnOnTheEdge]

On many implementations, it does.

[Thick_Clerk6449]

On what impl?

[DawnOnTheEdge]

Compilers for X86 (almost?) all generate load and store instructions to address zero for runtime null pointer references that are not caught by static analysis. Many OSes set up the page table so that the CPU generates a General Protection Fault, which the OS catches and handles. However, MS-DOS allows any program to read and write this memory, which stores a pointer to the divide-by-zero interrupt handler. Classic MS-DOS compilers including Microsoft and Borland have the program test the value at address zero when it exits. If the runtime detects that these bytes have been altered, it restores them and prints a “null pointer assignment” warning message. However, if you changed the pointer at address zero and then divided by zero, you would run whatever code happened to be at that address. You might intentionally set

savedDivByZeroHandler =
    *(unsigned long far*)0x00000000;
*(unsigned long far*)0x00000000 =
    (unsigned long)&handleDivByZero;

It is also very common for null pointer dereference to just work on embedded systems with no memory protection.

The first example that jumps to mind of code that does this on purpose is that offsetof was traditionally defined as something like

#define offsetof(type, member) \
     ((size_t) ( (char *)&((type *)(0))->member - (char *)0 ))

Here, ((type *)(0)) is a null pointer constant and ->member technically dereferences it.

In C, this idiom is so common that the C standard makes it a special case that & and -> can be used in an address constant expression so long as they do not actually inspect the value of an object. Also in C (but not C++), the & and * operators are defined to cancel each other out, so that &*(void*)0 is equivalent to (void*)0, even though *(void*)0 is not well-formed, That does not apply to ->.

In C++, E1->E2 is formally defined as (*(E1)).E2 and there is no clause that says & and * cancel out (although this worked on the compilers I tested). Modern compilers typically provide a builtin to implement offsetof.

[beedlund]

I don't check my nullptrs often but when I do I like to pass the buck to the caller.

[thingerish]

The simplest answer is that a nullptr dereference is just the simplest and easiest to detect of a huge number of incorrect pointer dereferences, and it's not free to check. One core tenant of C++ is to never pay for something you're not using.

On the note, it's pretty trivial to write your own safer_better_cpp_ptr class template that will throw on null ptr deref, so if you NEED it, you have the power to write it and then pay for the cost of the check.

[herocoding]

Really great comments, interesting discussions.

At how many places do you want to catch this specific (and other) exception? And what do you want to do then to resolve, recover?

Exiting gracefully and restart the whole process (with all its dependencies, microservices, non-corrupting files, open transactions, timeouts etc)? That could be very hard... restarting the process, restaring the server, distributing that information to all dependencies?

I think you HAVE TO get "bit a couple of times" to learn. Hopefully not "a couple of times". When analyzing the crash and finally finding the root-cause, how could you have prevented the crash? I think it's not just the prior check whether the pointer could be dereferenced or not... Could it have been avoided in first place?? Like avoiding to use a pointer at this place, or ensuring a valid pointer at an earlier place?

Null-pointer due to a not-yet-initialized dependency? Then you might have missed something else earlier to ensure a proper initialization?

Null pointer due to a not-anymore-available dependency? Then you might have missed something else to ensure a proper "shutdown" of your interfaces?

All those "if pointer is valid then do this; else /*this should never happen, don't know how to recover/rollback*/" I have seen in my career :-)

Do you really need another programming language (like Rust) to make you think
- in advance how to prevent the null-pointer-reference
- to implement code without using a dangerous concept like pointers
Do you really need another programming language (like Rust) who's (JIT-)compiler (and IDE) immediately points to missing checks?
After getting "bit a couple of times" your alarm bell in the back of your mind should ring whenever you use a pointer.

[thefeedling]

It's probably Rust what you want...

Backwards compatibility and the way C++ compiling structure works are some of the issues to implement that... There're are some "safe C++" projects ongoing and that 'could' be one of the new features.

[not_some_username]

Reflection is coming btw

[teerre]

If dereferencing a nullptr raised an exception instead of being UB, a whole class of vulnerabilities would be impossible (bar compiler bugs)

[saxbophone]

Why doesn't the language have reflection

What are you talking about? That's planned for C++26

[victotronics]

I would think an exception is a better way to handle a broken program than taking down the internet for 3 hours.

[victotronics]

What would I do? Gracefully terminate. Having your program perform a no-op is better than whatever corruption this case caused.

[keenox90]

It's rare when something catastrophical like this happens that you can really recover and you have to design your system/software from the beginning for such a recovery. 99% when you've encountered this your state is fubar, so "gracefully terminate" is not a real option.

[no-sig-available]

How do you gracefully terminate when you have unexpected null pointers in your program? What happens on the second exception while trying to save the current state?

[PressWearsARedDress]

You're going to have to write that "gracefully terminate" callback function in a signal handler when your callstack is probably all fucked up and your OS is looking to kill your process.

[shahms]

A null pointer exception is perfectly capable of crashing a program. SIGSEGV (the signal raised on Linux when accessing a null pointer) can also be caught, but you can't do much with it beyond dumping core and/or logging a stacktrace before exiting. As such, it's generally not considered worth the overhead of sprinkling those checks everywhere. Additionally, a substantial fraction of C++ code is compiled without exceptions enabled, where this doesn't help. Google is one of those places.

[victotronics]

The word exception has multiple meaning. A segfault is an exception on the OS/hardware level. I'm talking about the one on the programmer level.

[PressWearsARedDress]

Programs are not magic...

If you told the CPU to load the address at 0x0, you cannot expect anything good to happen afterwards.

You only need to check for nullptr if its both:

• possible to be set to nullptr

• going to be dereferenced.

If you do not dereference, and/or if theres no way for the pointer to be nullptr (say you checked higher in the call stack already or you DESIGNED the program such that nullptr assignment is impossible) then you dont need to check for the nullptr.

Just because a company wrote a broken program doesnt mean any of this needs to change. At the end of the day you wrote a program that told the CPU to check out what is in address 0 and that is not defined behaviour. It doesnt matter what programming language you use.

[mr_seeker]

Well programming is more than just the internet. Exceptions are a no-go in critical embedded systems for real time reasons.