Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!samsung!xanth!cs.odu.edu!kremer
From: kremer@cs.odu.edu (Lloyd Kremer)
Newsgroups: comp.lang.c
Subject: Re: sizeof a struc field
Message-ID: <10295@xanth.cs.odu.edu>
Date: 27 Oct 89 18:37:18 GMT
References: <7710@microsoft.UUCP> <11316@smoke.BRL.MIL> <7685@cdis-1.uucp> <1003@cirrusl.UUCP> <1503@crdos1.crd.ge.COM>
Sender: news@cs.odu.edu
Reply-To: kremer@cs.odu.edu (Lloyd Kremer)
Organization: Old Dominion University, Norfolk, VA
Lines: 26

In article <1503@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
>In article <1003@cirrusl.UUCP>, dhesi@sunseeker.UUCP (Rahul Dhesi) writes:
>
>|          sizeof ((type *)x)->member
>
>  If x is not a pointer type I'm sure you mean 
>	sizeof ((type *)&x)->member
>			^

I'm fairly sure he meant it the first way--an integral constant expression
to be used as a pointer to some object (in this case a struct) in a totally
non-portable way.

Uses include accessing interrupt vectors or memory-mapped devices such as
the video map or RAM designated for use by the system BIOS.

One problem that comes to mind (other than obvious non-portability) is the
familiar pointer alignment problem.  I think

	((type *)1)->member

would cause a trap on any machine requiring any alignment of "type".

					Lloyd Kremer
					kremer@cs.odu.edu
					Have terminal...will hack!