Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!agate!eos!shelby!csli!poser
From: poser@csli.Stanford.EDU (Bill Poser)
Newsgroups: comp.lang.c
Subject: Re: sizeof a struc field
Message-ID: <10787@csli.Stanford.EDU>
Date: 26 Oct 89 05:11:31 GMT
References: <7710@microsoft.UUCP> <680011@hpmwjaa.HP.COM> <11404@smoke.BRL.MIL> <10767@csli.Stanford.EDU> <1469@crdos1.crd.ge.COM>
Sender: poser@csli.Stanford.EDU (Bill Poser)
Reply-To: poser@csli.stanford.edu (Bill Poser)
Organization: Center for the Study of Language and Information, Stanford U.
Lines: 26

In article <1469@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen)
writes:
>  This [just doing sizeof(member) - BP] is just not practical unless
> you control the header file. There are times when a field in a
> structure may not be the same type (portably).

I have two reactions to this. The first is that people who distribute
libraries with headers that define structures with possibly variable
(across implementation or time) members are doing a poor job if they
don't either: (a) provide functions or macros which can be used to
obtain the necessary information or (b) use macro definitions so that
one can write,e.g. sizeof(INTEGRAL) instead of sizeof(int) or sizeof(short)
or whatever. The second is that it is good to have the means to get
around the deficiencies of suppliers who don't do this, so I will concede
the utility of being able to do sizeof(struct->member).

This makes me wonder whether it would not be worthwhile (in D, or whatever)
to treat struct_type.member_name as a type alias, so that if we had:

	struct foo{
		TYPE1 a;
		TYPE2 b;
	};

we could then use foo.a as a type, equivalent in this case to TYPE1.
This would allow, in particular, the usage sizeof(foo.a).