473,321 Members | 1,708 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,321 software developers and data experts.

offsetof( ) macro

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

Nov 8 '06 #1
11 2376
Kavya wrote:
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
Nov 8 '06 #2
Kavya wrote:
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?
Nov 8 '06 #3
Stuart Redmann wrote:
>
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.
Nov 8 '06 #4
Pete Becker wrote:
Stuart Redmann wrote:
>>
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*.
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
Nov 8 '06 #5
Stuart Redmann wrote:
>
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.
Nov 8 '06 #6
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" <pe********@acm.orgwrote in message news:yY******************************@giganews.com ...
Stuart Redmann wrote:
>
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.
Nov 9 '06 #7
Fred Zwarts wrote:
>
"Pete Becker" <pe********@acm.orgwrote in message news:yY******************************@giganews.com ...
>Stuart Redmann wrote:
>>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.
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.
Nov 9 '06 #8

Fred Zwarts wrote:
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

Nov 9 '06 #9
Fred Zwarts wrote:
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
cl*******@gmail.com
Nov 9 '06 #10
Stuart Redmann wrote:
Pete Becker wrote:
>Stuart Redmann wrote:
>>>
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*.

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?
No, it wouldn't. It dereferences a NULL pointer and is therefore undefined.
--
Clark S. Cox III
cl*******@gmail.com
Nov 9 '06 #11
"Greg" <gr****@pacbell.netwrote in message news:11**********************@h48g2000cwc.googlegr oups.com...

Fred Zwarts wrote:
>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.
Nov 10 '06 #12

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

44
by: Simon Morgan | last post by:
Hi, Can somebody please help me grok the offsetof() macro? I've found an explanation on http://www.embedded.com/shared/printableArticle.jhtml?articleID=18312031 but I'm afraid it still...
8
by: Pawel | last post by:
Hallo group members. //p1.cpp #include <stdio.h> #include <linux/stddef.h> struct Person { int m_age; char* m_name; };
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.