confusing macro

[Mantorok Redgormor]

#define FOO(x,y) ((int)&(((x*)NULL)->y))

How is this legal? It is accessing the member of a struct whose
address is "zero". Since NULL is zero.

[Joona I Palaste]

Mantorok Redgormor <ne*****@tokyo.com> scribbled the following:

#define FOO(x,y) ((int)&(((x*)NULL)->y)) How is this legal? It is accessing the member of a struct whose
address is "zero". Since NULL is zero.

It depends. On some implementations, & and -> cancel each other out,
leaving essentially a pointer substraction. On others, they don't. The
moral of the story is: The implementation writer is allowed to define
such a macro. You are not.
("You" meaning every common programmer, not just Mantorok.)

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"I wish someone we knew would die so we could leave them flowers."
- A 6-year-old girl, upon seeing flowers in a cemetery

[Dan Pop]

In <41*************************@posting.google.com> ne*****@tokyo.com (Mantorok Redgormor) writes:

#define FOO(x,y) ((int)&(((x*)NULL)->y))

How is this legal? It is accessing the member of a struct whose
address is "zero". Since NULL is zero.

It's not legal, but it works because it doesn't actually access the
member, it merely takes its address. If you replace int by size_t, you
get the typical implementation of the offsetof macro from <stddef.h>.

Strictly speaking, it is invoking undefined behaviour, but I have yet
to see a real world implementation where it doesn't work as intended.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Micah Cowan]

ne*****@tokyo.com (Mantorok Redgormor) writes:

#define FOO(x,y) ((int)&(((x*)NULL)->y))

How is this legal? It is accessing the member of a struct whose
address is "zero". Since NULL is zero.

It's not. However, you probably pulled this from a system header
(defining offsetof(), no doubt). System headers are allowed to make
all sorts of assumptions about the implementation, and even invoke
behavior which is undefined by the Standard, so long as they no that
the behavior is "defined" for their particular implementation.

The moral of the story? Don't write code like the above (unless your
an Implementor), but don't trip if you come across it in a system
header.

-Micah

[Mantorok Redgormor]

Da*****@cern.ch (Dan Pop) wrote in message news:<bk**********@sunnews.cern.ch>...

In <41*************************@posting.google.com> ne*****@tokyo.com (Mantorok Redgormor) writes:

#define FOO(x,y) ((int)&(((x*)NULL)->y))

How is this legal? It is accessing the member of a struct whose
address is "zero". Since NULL is zero.
It's not legal, but it works because it doesn't actually access the
member, it merely takes its address. If you replace int by size_t, you
get the typical implementation of the offsetof macro from <stddef.h>.

Strictly speaking, it is invoking undefined behaviour, but I have yet

Why does it invoke undefined behaviour? Could you refer me to a
relevant section in the standard that states the reason? And where in
the standard does it state that & -> cancel each other out?
to see a real world implementation where it doesn't work as intended.

Dan

[Joona I Palaste]

Mantorok Redgormor <ne*****@tokyo.com> scribbled the following:

Da*****@cern.ch (Dan Pop) wrote in message news:<bk**********@sunnews.cern.ch>...

In <41*************************@posting.google.com> ne*****@tokyo.com (Mantorok Redgormor) writes:

>#define FOO(x,y) ((int)&(((x*)NULL)->y))
>
>How is this legal? It is accessing the member of a struct whose
>address is "zero". Since NULL is zero.
It's not legal, but it works because it doesn't actually access the
member, it merely takes its address. If you replace int by size_t, you
get the typical implementation of the offsetof macro from <stddef.h>.

Strictly speaking, it is invoking undefined behaviour, but I have yet Why does it invoke undefined behaviour? Could you refer me to a
relevant section in the standard that states the reason? And where in
the standard does it state that & -> cancel each other out?

It invokes undefined behaviour *precisely* because the standard does
*not* say that & and -> cancel each other out.
to see a real world implementation where it doesn't work as intended.

This is irrelevant. As long as the standard doesn't require it, an
implementation where this sort of macro would not work is fully legal.
The compiler writer knows what works on his/her compiler and what does
not - therefore he/she can write macros like these like no one's
business, as long as they don't directly contradict the standard. You,
on the other hand (meaning Mantorok, Dan Pop, myself, and pretty much
everyone else), can not.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"This isn't right. This isn't even wrong."
- Wolfgang Pauli