Hacker News Reader

Comment by unwind | Hacker News Reader

That, of course, would be a leading question. Most people would probably tend to assume that you're asking "in the environment in which we're programming, what happens if you dereference NULL?" which is not what you meant.

I didn't poll my coworkers either, but at least I think the answers would be different if I asked "what does C say should happen when a NULL pointer is dereferenced?".

Perhaps that's just wishful thinking on my behalf, though. :)

View on HN

I don't think that's particularly wishful thinking, however, your alternative phrasing could be seen as equally, if not more, leading.

When quizzed on the behaviour of a C program I would expect a careful and experienced C programmer to consider the behaviour described by the standard (which standard?); unspecified and implementation defined behaviours; and deviations from the standard in both the compiler and the environment. Often I'd expect the answer to be "it depends".

I think, once you unanimously conclude that something should not be done, that people don't really care _why_ it shouldn't be done until someone tries to suggest you should do it.

For example, we know not to dereference null pointers. It is pretty much never correct to do so, and it's hard to imagine otherwise. What does it matter what C says should happen when you do it? You're never going to intentionally do it, so it becomes an incongruous hypothetical. Like "what would happen if you were never born?" The answer is useless because the question is inherently flawed.

Good point. Some embedded environments will have different behavior. I don't recall what happened under MS DOS or if MS compiler provided an debug option.

Clang, for example, will optimize out some NULL dereferences. So even in real environments that people use, "it segfaults" is wrong.

Edit: some NULL dereferences.

In that case the machine code generated doesn't dereference NULL, so the answer "it segfaults" isn't wrong.

In the C code, a null pointer is dereferenced. A segfault is not happening in the executable. Arguing about intermediate steps is kinda moot IMO.

The very concept of dereferencing doesn't exist at that level.

I'll take the downvote as a request for elaboration. In C, you dereference a pointer. This typically translates to machine code that loads memory at an address. The translation is so direct that we tend to think of them as identical, i.e. dereferencing a pointer is loading memory at an address. But this is not so; first of all, nothing says pointers have to be implemented as memory addresses in the first place, and even if you do implement them that way (as virtually every C implementation does), not every pointer dereference has to generate a load instruction. That's not just the case for optimizing out NULL dereferences. Optimizations mean that in general, an expression p can have the memory load optimized away if the value at that location is already known from a previous computation (say, because you just assigned a value there, or you read the value a bit earlier and it's still available in a register).
In C, you deference a pointer. In assembly or machine code, you load memory at an address. The two don't have to happen at the same time, though, and just because you don't end up loading memory at an address doesn't mean you didn't dereference a pointer.
In short:
*(char *)NULL
This always dereferences NULL, even if the compiler optimizes out the statement entirely.

Reply on news.ycombinator.com