null pointer exception handling in C

[Candamir]

Code: Select all

#define NULL ((void *)0) // Standard C NULL definition
...

typedef struct
{
   unsigned int something;
} xyz_t;

xyz_t *x = NULL;
unsigned int y = x->something;

How is the behaviour of this code defined? Is there an interrupt or is y simply NULL also?

Candamir

[Candy]

By the standard, I think that should give a null pointer exception. In Linux you'd get a segfault, in a kernel you'd get whatever is at address 0 if mapped, or a page fault / something like it if nothing is mapped.

[Kemp]

Running in userland under most OSs will give you some sort of exception and probably terminate the application (assuming nothing in your code tries to catch and recover). In C++ you could try to handle it yourself, afaik C doesn't provide that sort of facility. In MSVC++ in a debug build it'll moan at you about it and ask you what you want to do.

[Candamir]

You were right Candy: It page faults.
Thanks,

Candamir

[Pype.Clicker]

i'd say that's a typical "undefined behaviour" ... On a system that has no memory protection mechanism, it'd simply lead to chaos and madness, but it wouldn't generate "exceptions" of any kind.

Just don't follow null pointers. period.

[Solar]

On "classic" AmigaOS, you would just have read a zero. If your struct had a second int member, you could read that to receive ExecBase (the pointer to the kernel function offset table). Exceptions, SEGFAULT? No, sir...

(Just to reinforce what Pype said. Don't touch NULL.)

[Candy]

In my OS, last boot loader, you could read the IVT and the boot parameter struct that was passed along. If you did that after splitting off your own process space, or in fact any address <0xC0000000, you'd get a GPF.

[Pype.Clicker]

In my OS, last boot loader, you could read the IVT and the boot parameter struct that was passed along. If you did that after splitting off your own process space, or in fact any address <0xC0000000, you'd get a GPF.

Well, yes, homebrew systems are typically having their own behaviour here ... I was more speaking of what you could encounter when dev'ing under e.g. MS-DOS (0000:0000 being a very valid read address and a very naughty place to write), embedded systems, handheld, game consoles and the like.

Imagine you have a NULL pointer dereferenced there (without error), all your "NULL" instance are a magically aliased object that is of all classes and which content may arbitrarily change (because another 'NULL' object has been used).
quite a nightmare, uh? Guess why all OSes where an MMU is available enforce that NULL is somewhere you cannot even read!