Question about -> dereferencing

Hi,

Code:

---

struct blah {
    int a;
    int b;
};
struct blah *tmp = (struct blah *) 0;
printf("%p\n", &tmp->b);

---

This is essentially the code to find the offset of member 'b' from the beginning of the struct 'blah'. The book I was reading said typecasting 0 into the struct 'blah' was fine as long as we didn't dereference it. I agree with that, but I see that the code uses the '->' operator in conjunction with the '&' to get the address. I was under the impression that 'tmp->b' is basically synonymous to '(*tmp).b'. Doesn't this imply that 'tmp' would first be dereferenced before the address is gotten? If so, shouldn't it be an out of bounds error? Or is it fine because the compiler optimises it somehow so that 'tmp' is never actually dereferenced? Any insight would be appreciated. Thanks in advance.

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

For starters create an object of that type ie struct blah before you dive into getting the offset of any of its members.

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

---

Quote:

---

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.

Quote:

---

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.

Quote:

---

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

Thanks guys. Yeah, as many of you have guess the code I presented is basically how the offsetof macro is defined sometimes. I was just trying to figure out how it worked. Thanks for all those that answered and thanks matsp especially, your last comment really cleared it up.

By the way...does this mean that Turbo C does not comply with the c99 standards because it caught the null pointer dereference?

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