Hacker News new | ask | show | jobs
by ape4 4170 days ago
Yeah, hopefully if you are programming in C you'll know using an undefined variable is bad.
1 comments

Yep. :-)

The article doesn't make much sense at times: Dereferencing a NULL Pointer: >>>contrary to popular belief<<<, dereferencing a null pointer in C is undefined.

I guess C programmers are not counted in the "popular" group.

I don't think it's wrong at all. I suspect if you asked a large number of even moderately competent C programmers, you'd find quite a lot of them believe it's defined to trap. That's exactly what the rest of it is talking about. Never mind the issue raised of how it potentially affects optimization, which I think very few C programmers would actually be able to speak to.
Are you really sure that most C programmers know about this?

IMO, if you'd ask the question "what happens if you dereference a NULL pointer", most C programmers would answer "a segfault".

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. :)

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.
If you are in a company that codes largely in C, do a pool and report back. I'm honestly curious.
Unfortunately, I don't work in such a company.

A completely unrepresentative poll among two C++ programmers showed that 50% thought it was a segfault, whereas the other 50% suggested it could be undefined behavior, deducing that from the knowledge that the behavior is different in Linux userspace and kernel.

Although I wouldn't call those two typical C++ programmers. They do security CTFs for fun, so they might have a broader knowledge about exploitable behaviors in C/C++ code.

For a while you were actually able to mmap the memory at address NULL under linux, which is usable for exploiting (you can pass arbitrary data to kernel code that you can bring to dereference null pointers)
Wouldn't virtual address translation prevent this from happening?