Thread: 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?

Thanks.

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.

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