offsetof( ) macro

Discussion in 'C++' started by Kavya, Nov 8, 2006.

  1. Kavya

    Kavya Guest

    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?.
     
    Kavya, Nov 8, 2006
    #1
    1. Advertising

  2. Kavya

    Kai-Uwe Bux Guest

    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
     
    Kai-Uwe Bux, Nov 8, 2006
    #2
    1. Advertising

  3. 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?
     
    Stuart Redmann, Nov 8, 2006
    #3
  4. Kavya

    Pete Becker Guest

    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.
     
    Pete Becker, Nov 8, 2006
    #4
  5. 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
     
    Stuart Redmann, Nov 8, 2006
    #5
  6. Kavya

    Pete Becker Guest

    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.
     
    Pete Becker, Nov 8, 2006
    #6
  7. Kavya

    Fred Zwarts Guest

    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" <> wrote in message news:...
    > 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.
     
    Fred Zwarts, Nov 9, 2006
    #7
  8. Kavya

    Pete Becker Guest

    Fred Zwarts wrote:
    >
    > "Pete Becker" <> wrote in message news:...
    >> 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.
     
    Pete Becker, Nov 9, 2006
    #8
  9. Kavya

    Greg Guest

    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
     
    Greg, Nov 9, 2006
    #9
  10. 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
     
    Clark S. Cox III, Nov 9, 2006
    #10
  11. 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
     
    Clark S. Cox III, Nov 9, 2006
    #11
  12. Kavya

    Fred Zwarts Guest

    "Greg" <> wrote in message news:...
    >
    > 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.
     
    Fred Zwarts, Nov 10, 2006
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Hiroki Horiuchi

    g++ "offsetof" problem

    Hiroki Horiuchi, Nov 25, 2003, in forum: C++
    Replies:
    5
    Views:
    6,713
    red floyd
    Nov 25, 2003
  2. Simon Morgan

    offsetof() macro

    Simon Morgan, Sep 8, 2005, in forum: C Programming
    Replies:
    44
    Views:
    1,347
    Tim Rentsch
    Sep 14, 2005
  3. Pawel
    Replies:
    8
    Views:
    944
    Default User
    Oct 19, 2006
  4. Christopher Benson-Manica

    Re: offsetof macro and non-POD structures. Solution.

    Christopher Benson-Manica, Oct 18, 2006, in forum: C++
    Replies:
    2
    Views:
    449
    Default User
    Oct 18, 2006
  5. Shao Miller

    offsetof() Macro Attempt

    Shao Miller, Jun 3, 2011, in forum: C Programming
    Replies:
    45
    Views:
    1,424
    Tim Rentsch
    Jul 3, 2011
Loading...

Share This Page