Re: offsetof
- From: darkknight <gp.kiwi@xxxxxxxxx>
- Date: Fri, 30 Sep 2005 23:42:25 +1200
On 30 Sep 2005 10:24:20 GMT, Richard Tobin wrote:
>In article <1128074405.066074.296020@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
> <junky_fellow@xxxxxxxxxxx> wrote:
>
>>> #define offsetof(type, mem) ((size_t) \
>>> ((char *)&((type *)0)->mem - (char *)(type *)0))
>
>>The second member of sustraction would be required on implementation
>>where the NULL pointer is *not* represented by all-bits-zero.
>
>The subtraction is required because you want an integer, not a
>pointer.
>
>Whether ((type *)0)->mem cast to an integer would give the right
>answer depends on how pointer-to-integer conversion works, not just on
>the representation of the null pointer.
>
>But the definition is non-portable because ((type *)0)->mem is undefined.
>
No it isn't. The arrow operator does not require an lvalue as its left
operand (and it hasn't got one here). There is no "evaluation of an
illegal lvalue" occurring here and no undefined behaviour.
The result of the above expression is an lvalue even though (type*)0 is
not an lvalue. Applying the address of operator & to the above
expression produces a pointer (rvalue) and still no undefined behaviour,
even if there are alignment issues.
darkknight
.
- References:
- offsetof
- From: luke
- Re: offsetof
- From: junky_fellow
- Re: offsetof
- From: Richard Tobin
- offsetof
- Prev by Date: Re: offsetof
- Next by Date: Re: Universal (g)libc
- Previous by thread: Re: offsetof
- Next by thread: Re: offsetof
- Index(es):
Relevant Pages
|