Thread: offsetof

  1. #1
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002

    Thumbs up offsetof

    In the past I'd run across some contradictory recommendations regarding the standard macro offsetof. I happened upon a use for it in some code I am developing, but was wary of distant memories.

    In the MISRA guidlines, summarized for Jean LaBrosee's Micro-C/OS-II, it states the following for Rule 120 (page 7).
    The macro offsetof, in library <stddef.h>, shall not be used.
    And in another piece I found while searching the web, there is this.
    Rule 120: The offsetof macro is a portable method of obtaining the offset of a struct member. The only undefined behavior applies to bit-fields.

    This rule should state: 'The use of offsetof is recommended.'
    I'd surfed comp.lang.c and found some information (which is as fun as always to interpret), but I am wondering if anyone here has any input regarding the use of offsetof? Why did MISRA give it a "shall not be used"? Are there other considerations besides portability?

    Last edited by Dave_Sinkula; 06-21-2003 at 10:21 AM.
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

  2. #2
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    The edge of the known universe
    The actual text of rule 120 is
    Use of this macro can lead to undefined behaviour when the types of the operands are incompatible or when bit fields are used.
    Now I've no idea what the first part is trying to say - the critique just ignores it and re-affirms the undefined behaviour of bit-fields.
    It seems to be suggesting that if you have offsetof(T,m), that the compiler can fail to warn you if T is not a struct/union, or m is not a member of T.
    But that would mean the compiler is broken in my opinion.

    In C99, offsetof() is defined as having a result type of size_t. I don't have C89 to hand - perhaps it was suggesting that offsetof() just returned an integral type, and was vague about whether that was int, unsigned long or whatever.

    Another suggestion would be that if you have a union, the offset of one union member is actually a 'padding' byte in another union member. But that's nothing new, there are plenty of other ways to abuse unions by writing to one union and accessing another - a common example being the hack to determine the endian-ess of a machine.

    Some of the discussion on c.l.c seems to centre on the implicit reference to the NULL pointer. Now I've only been checking with gcc (so don't extrapolate too far), offsefof() is evaluated entirely in the compiler.
    However, if you have an array inside the struct, and you try
    &nbsp;&nbsp;&nbsp;&nbsp;offsetof( struct_with_array, array[some_var] )
    then it becomes a run-time calculation, and some implementations may be finding that NULL problematic.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  3. #3
    End Of Line Hammer's Avatar
    Join Date
    Apr 2002
    >>I don't have C89 to hand
    I do, here you go...:
    4.1.5 Common definitions <stddef.h>

    offsetof( type, member-designator)

    which expands to an integral constant expression that has type size_t,
    the value of which is the offset in bytes, to the structure member
    (designated by member-designator ), from the beginning of its
    structure (designated by type ). The member-designator shall be such
    that given

    static type t;

    then the expression &(t. member-designator ) evaluates to an address
    constant. (If the specified member is a bit-field, the behavior is
    When all else fails, read the instructions.
    If you're posting code, use code tags: [code] /* insert code here */ [/code]

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. offsetof
    By hzmonte in forum C Programming
    Replies: 10
    Last Post: 10-27-2008, 08:57 AM