Thread: Question about -> dereferencing

Which is why we use the offsetof() macro.
offsetof - Wikipedia, the free encyclopedia

You can usually do this in practice, but it's not correct. You need to either create one of these structs for real, or use offsetof().

Unless you're doing something really, really weird, though, I don't know why you'd need to know the offset of a particular member in a struct.

At least one compiler I know of (Turbo C -- sigh) catches NULL dereferences and prints "NULL pointer dereference" instead of segfaulting.

You're right, though -- my gcc (4.3) doesn't segfault and in fact works as "expected".

Code:

$ ./nooffset
0x4
$

I'd guess that that's a compiler extension.

If I look at the generated assembly, even with optimizations disabled, I see GCC moving a hard-coded '4' into a register. For what it's worth, at least one library seems to be using this extension to implement offsetof.

Code:

slang.h:2252:# define offsetof(T,F) ((unsigned int)((char *)&((T *)0L)->F - (char *)0L))

Originally Posted by dwks

At least one compiler I know of (Turbo C -- sigh) catches NULL dereferences and prints "NULL pointer dereference" instead of segfaulting.

That's absolutely critical on DOS. A far pointer which points to NULL, if written to, will destroy the first entry of the interrupt vector table -- the timer vector -- which is pretty much guaranteed to crash the whole system within 1/18.2th of a second

I'd be very surprised if even Turbo C generated a fault with this bit of code, though. Nothing actually needs to be dereferenced, so no l-value or r-value needs to be generated by the compiler.

Originally Posted by brewbuck

That's absolutely critical on DOS. A far pointer which points to NULL, if written to, will destroy the first entry of the interrupt vector table -- the timer vector -- which is pretty much guaranteed to crash the whole system within 1/18.2th of a second

Actually, the first 8 entries in the interrupt vector table is taken by the exception vectors, the first one being division by zero.

But certainly, any overwriting of the vector table is likely to lead to very bad things.

Unfortunately, Turbo C only catches references to exactly NULL, not other invalid accesses that are a bit from NULL - such as perhaps the vectors for the timer interrupt.

I'd be very surprised if even Turbo C generated a fault with this bit of code, though. Nothing actually needs to be dereferenced, so no l-value or r-value needs to be generated by the compiler.

Sure, I do not think any compiler will actually dereference NULL to get the address.

However, as pointed out, there is an offsetof macro defined in most compilers (is it part of the standard even, I can't remember). Certainly, creating a variable just to hold a zero-value is not ideal. If you must do these sort of things, do this:

Code:

#define myoffset(T, element) &(*T)(0)->element

--
Mats

Code:

$ man offsetof
...
CONFORMING TO
       C89, C99, POSIX.1-2001.
...

By the way, there is no way that the compiler should ever dereference the pointer if you use & on a ptr->x element. It will read the pointer value itself, and add the offset of x. There is no reason, and in fact in some situations (drivers with hardware registers) it would lead to incorrect behaviour to access ptr->x (say it's a fifo-register that changes when being read!)

--
Mats

Turbo C doesn't comply with C99. Not sure if it really complies fully with C90 either.
It's a very old compiler (hence should be avoided).