peter@objy.objy.com (Peter Moore) (10/01/90)
The validity of sizeof((type *)->field)) is especially interesting given
the sample (though carefully described as unportable) definitions of offsetof
in the Rationale (4.1.5: pg 75):
#define offsetof(type, field) (size_t)&(((type*)0)->field)
This isn't going to work if sizeof((type *)->field) doesn't work.
By the way, the above definition of offsetof always seemed like a bad one,
since it makes the unnecessary assumption that the null pointer has a 0
bit-pattern. Now practically, that is probably true for almost all compilers,
if only because there is so much code that implicitly depends on it. But
wouldn't a more politically correct example be:
#define offset(type, field) \
( ((char *) &(((type *)0)->field)) - ((char *) 0) )
Peter Moore
peter@objy.comsteve@taumet.com (Stephen Clamage) (10/03/90)
peter@objy.objy.com (Peter Moore) writes: >The validity of sizeof((type *)->field)) is especially interesting given >the sample (though carefully described as unportable) definitions of offsetof >in the Rationale (4.1.5: pg 75): >#define offsetof(type, field) (size_t)&(((type*)0)->field) >This isn't going to work if sizeof((type *)->field) doesn't work. But offsetof is supplied by the compiler implementor, and whatever is supplied must work with the implementation. There is no guarantee that vendor A's offsetof will work with vendor B's compiler. That is why it is part of the standard header supplied with the compiler. You simply #include <stddef.h> and use offsetof. Your code is guaranteed to work with any conforming implementation. There is no guarantee that YOU can write a portable offsetof. -- Steve Clamage, TauMetric Corp, steve@taumet.com
scjones@thor.UUCP (Larry Jones) (10/11/90)
In article <469@taumet.com>, steve@taumet.com (Stephen Clamage) writes: > There is no guarantee that YOU can write a portable offsetof. In fact, you can't. That's why offsetof was adopted for the standard. ---- Larry Jones UUCP: uunet!sdrc!thor!scjones SDRC scjones@thor.UUCP 2000 Eastman Dr. BIX: ltl Milford, OH 45150-2789 AT&T: (513) 576-2070 Why can't I ever build character in a Miami condo or a casino somewhere? -- Calvin
jfc@athena.mit.edu (John F Carr) (03/07/91)
Is the following legal C?
struct foo { struct bar { int a;} b;};
offsetof(struct foo, a.b);
Section 4.1.5 of the standard doesn't explicitly disallow this, but I wasn't
able to find definitions elsewhere that would tell me if "a.b" is a
structure member or not.
The only compiler I've found that doesn't use some variant of
#define offsetof(t,m) (size_t)&((struct t *)0)->m
for offsetof does not allow offsetof(struct foo, a.b). Is it wrong?
--
John Carr (jfc@athena.mit.edu)gwyn@smoke.brl.mil (Doug Gwyn) (03/11/91)
In article <1991Mar6.232854.22267@athena.mit.edu> jfc@athena.mit.edu (John F Carr) writes: >Is the following legal C? > struct foo { struct bar { int a;} b;}; > offsetof(struct foo, a.b); >Section 4.1.5 of the standard doesn't explicitly disallow this, but I wasn't >able to find definitions elsewhere that would tell me if "a.b" is a >structure member or not. (1) You mean "b.a", not "a.b". (2) You mean "designates", not "is". (3) The wording in the description of offsetof() was carefully chosen to permit "dotted" member designators such as you attempted to use.