Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ukma!tut.cis.ohio-state.edu!att!cbnewsl!dfp
From: dfp@cbnewsl.ATT.COM (david.f.prosser)
Newsgroups: comp.std.c
Subject: Re: Two standards problems
Message-ID: <841@cbnewsl.ATT.COM>
Date: 19 Jun 89 20:22:55 GMT
References: <178@ixi.UUCP <183@ixi.UUCP> <800@cbnewsl.ATT.COM> <10412@smoke.BRL.MIL>
Reply-To: dfp@cbnewsl.ATT.COM (david.f.prosser)
Organization: AT&T Bell Laboratories
Lines: 79

In article <10412@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <800@cbnewsl.ATT.COM> dfp@cbnewsl.ATT.COM (david.f.prosser) writes:
>>	#define XtOffset(p, m) offsetof(*(p), m)
>
>In preparing my previous response to the question, I considered something
>similar, but it wasn't clear to me from the draft Standard exactly what
>was acceptable for the "type" argument to offsetof().  In particular the
>use of
>	static type t;
>in the Standard bothered me; if one substitutes literally for "type" in
>that template, will constructs such as "*(p)" where "p" is a type name
>work?  Some types need the identifier "t" buried inside them.  Anyway,
>the proper declaration in this case would seem to be
>	static p *t;
>so shouldn't the "type" argument to offsetof() be "p*"?  I don't think
>this was specified clearly enough in the draft (although I would be happy
>to be proved wrong on this point).

Doug makes an interesting case on this point.  The complete pANS description
for offsetof is:

	The macros [in <stddef.h>] are ... and

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

The most common implementation of offsetof (and mentioned as such in the
Rationale) is probably close to

	#define offsetof(t, m) ((size_t)&(((t *)0)->m))

but this just doesn't "cut it" with the interpretation that _type_ is only
constrained by the "static _type_ t;" construct.  With an implementation of

	#define XtOffset(p, m) offsetof(p *, m)

an invocation of

	XtOffset(x, a.b)

produces

	((size-t)&(((x * *)0)->a.b))

which casts 0 to be a pointer to a pointer to an x (which in the original
was a pointer to the structure in question).  By this, it is clear that the
Committee's intent with respect to offsetof was not to allow an arbitrary
substitution for _type_ in the pseudo-declaration.

Unfortunately, the only support (just from the pANS) for this was the
note that a structure is designated by _type_.  Given that one can designate
a structure either by a prefix * applied to an expression with structure
pointer type, or a postfix * in a declaration in which the type specifier is
a structure pointer, you are right that the words are not completely clear.
(The Committee did not think about the second case, I'm sure.)

As I recall, this description was used so that a chain of members (e.g.
a.b.c) would be valid, which the previous description did not permit.

This is exactly the sort of ruling that the interpretations phase would
produce.  In this case, the Rationale clarifies the pANS, so the above
form for XtOffset is not valid.

I still believe that the only means to build a structure type from a
structure pointer type name is through name creation with the ## operator,
as I outlined in my previous posting.

Dave Prosser	...not an official X3J11 answer...