offsetof( ) macro

[Kavya]

offsetof(T,m) (size_t)&(((T*)0)->m)

Why do we always start from 0 in this macro to access the offset of
structure or union. Does standard guarantees that structure and union
reside at address 0? If yes, then what if I have two or more
structures. How can they reside at same address?.

 

[Kai-Uwe Bux]

offsetof(T,m) (size_t)&(((T*)0)->m)

Why do we always start from 0 in this macro to access the offset of
structure or union. Does standard guarantees that structure and union
reside at address 0?

No. The macro involves undefined behavior. I presume you found this macro in
the code of your standard library implementation: note that the implementor
of the standard library for your compiler is allowed to use code that has
undefined behavior as long as the compiler guarantees the right behavior
(even though the standard does not require it). Alternatively, offsetof
could be implemented using compiler magic.

If yes, then what if I have two or more structures. How can they reside at
same address?.

They don't; and the compiler would complain if it wasn't for the casts
telling it to shut up.


Best

Kai-Uwe Bux

 

[Stuart Redmann]

offsetof(T,m) (size_t)&(((T*)0)->m)

Why do we always start from 0 in this macro to access the offset of
structure or union. Does standard guarantees that structure and union
reside at address 0? If yes, then what if I have two or more
structures. How can they reside at same address?.

This is only a pretty hack. Keep in mind that structures or unions have
no address as they only define the memory layout and the behaviour of
real objects of this type. In this offsetof hack above we take a pointer
to one instance x of type T and compute the difference between &(x->m)
and &x. Of course, the pointer we use is not valid, that means we cannot
dereference it without provoking undefined behaviour. So we could choose
just any pointer value:
#define offsetof(T,m) (size_t)(&(((T*) 0x12345678)->m) - &((T*)
0x12345678)))
would work as well, but it is not clear why we used this particular
pointer 0x12345678. So we stick to the NULL pointer, which happens to
coincide with the virtual address 0x00000000 on some platforms (this
version of offsetof is not very portable, BTW). This way we don't need
to subtract the second term &((T*) 0), as this would evaluate to
0x00000000 anyway (all pointer values in this example are only valid for
32 bit machines).

A more platform-independent version of offsetof would be:
#define offsetof(T,m) (size_t)(&(((T*)0)->m) - &((T*)0))

Regards,
Stuart

@ALL: Shouldn't this be in the FAQ?

 

[Pete Becker]

A more platform-independent version of offsetof would be:
#define offsetof(T,m) (size_t)(&(((T*)0)->m) - &((T*)0))

Don't try and write platform-independent versions of standard library
hacks. One of the main reasons offsetof is in the standard library is
that it can't be written portably.

Note, too, that this version just doesn't work. It's ill-formed unless m
and T are related types, and even then, it gets the wrong answer. You
need to cast both pointers to some flavor of char*. By the time you've
done that, it'll be pretty much unreadable.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

 

[Stuart Redmann]

Don't try and write platform-independent versions of standard library
hacks. One of the main reasons offsetof is in the standard library is
that it can't be written portably.

Note, too, that this version just doesn't work. It's ill-formed unless m
and T are related types, and even then, it gets the wrong answer. You
need to cast both pointers to some flavor of char*.

Yes, I'm sorry for overlooking this.

By the time you've
done that, it'll be pretty much unreadable.

Agreed. But it would be portable, wouldn't it?

Stuart

 

[Pete Becker]

Agreed. But it would be portable, wouldn't it?

It has the same problem as the original version: it dereferences a null
pointer. But what's the point? You're fine tuning edge cases that are
already handled in the standard library. Let the library do it.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

 

[Fred Zwarts]

The problem is that the standard library does not cover all cases.
It only handles compile time constant offsets.
In order to calculate run-time offsets one needs to use a macro.
Example:

struct T {
int I[10];
};

size_t F (int J) {
return offsetof (T,I[J]);
}

This does not compile with some compilers, because the offset
cannot be determined at compile time. In such a case one
needs to fall back to a macro. It might be undefined according to
the standard, but it turns out that it works on almost all platforms
and the standard offers no alternative.

Fred.Zwarts.

 

[Pete Becker]

It has the same problem as the original version: it dereferences a null
pointer. But what's the point? You're fine tuning edge cases that are
already handled in the standard library. Let the library do it.

> The problem is that the standard library does not cover all cases.
> It only handles compile time constant offsets.
> In order to calculate run-time offsets one needs to use a macro.
> Example:
>
> struct T {
> int I[10];
> };
>
> size_t F (int J) {
> return offsetof (T,I[J]);
> }
>
> This does not compile with some compilers, because the offset
> cannot be determined at compile time. In such a case one
> needs to fall back to a macro. It might be undefined according to
> the standard, but it turns out that it works on almost all platforms
> and the standard offers no alternative.
>

That may well be a legitimate problem, but the proposed macro didn't
claim to solve it, nor does it. The proposed macro is no more portable
than the usual library solution, and the library solution has the
advantage of working on all platforms. That's why it's in the library:
so that you don't have to deal with compiler quirks.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

 

[Greg]

The problem is that the standard library does not cover all cases.
It only handles compile time constant offsets.
In order to calculate run-time offsets one needs to use a macro.
Example:

struct T {
int I[10];
};

size_t F (int J) {
return offsetof (T,I[J]);
}

This does not compile with some compilers, because the offset
cannot be determined at compile time. In such a case one
needs to fall back to a macro. It might be undefined according to
the standard, but it turns out that it works on almost all platforms
and the standard offers no alternative.

But F() could be written so that it would return the correct offset on
all platforms:

size_t F( int j )
{
return offsetof(T, I) + j * sizeof( int );
}

Greg

 

[Clark S. Cox III]

The problem is that the standard library does not cover all cases.
It only handles compile time constant offsets.
In order to calculate run-time offsets one needs to use a macro.
Example:

struct T {
int I[10];
};

size_t F (int J) {
return offsetof (T,I[J]);
}

This does not compile with some compilers, because the offset
cannot be determined at compile time. In such a case one
needs to fall back to a macro. It might be undefined according to
the standard, but it turns out that it works on almost all platforms
and the standard offers no alternative.

#define OFFSETOF_ARRAY(type, member, index) \
(offsetof(type,member) + index * \
sizeof(static_cast<const type*>(0)->member[0]))

size_t F (int J) {
return OFFSETOF_ARRAY(T,I,J);
}

 

[Clark S. Cox III]

Yes, I'm sorry for overlooking this.


Agreed. But it would be portable, wouldn't it?

No, it wouldn't. It dereferences a NULL pointer and is therefore undefined.

 

[Fred Zwarts]

The problem is that the standard library does not cover all cases.
It only handles compile time constant offsets.
In order to calculate run-time offsets one needs to use a macro.
Example:

struct T {
int I[10];
};

size_t F (int J) {
return offsetof (T,I[J]);
}

This does not compile with some compilers, because the offset
cannot be determined at compile time. In such a case one
needs to fall back to a macro. It might be undefined according to
the standard, but it turns out that it works on almost all platforms
and the standard offers no alternative.

But F() could be written so that it would return the correct offset on
all platforms:

size_t F( int j )
{
return offsetof(T, I) + j * sizeof( int );
}

Greg

Yes, for this simple example. But in more complex cases it would be nice if the
compiler did the arithmetic for the indices, in particular if this must be done many
times for different complex structures.