Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!basil.usc.edu!blarson
From: blarson@basil.usc.edu (bob larson)
Newsgroups: comp.lang.c
Subject: Re: struct accessing
Message-ID: <18255@usc.edu>
Date: 4 Jul 89 09:43:46 GMT
References: <1545@stl.stc.co.uk> <470002@gore.com> <1411@garcon.cso.uiuc.edu>
Sender: news@usc.edu
Reply-To: blarson@basil.usc.edu (bob larson)
Organization: USC AIS, Los Angeles
Lines: 24

In article <1411@garcon.cso.uiuc.edu> mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) writes:
>There is a special dispensation, though: "If a pointer to a structure
>is cast to the type of a pointer to its first member, the result
>refers to the first member".  [8.3]

There is at least one current (non-ansi) compiler that does not do this
currently, and will be forced to have extra overhead if the first structure
member is a char.  Prime 50 series computers arn't byte addressable%, and
the ix mode C compiler avoids the overhead of bit field insert/extract
on char variables not part of an array by treating them as shorts.  (char
is unsigned by default, signed char will be rather nasty to implement.)

64v mode C on the Prime puts char variables in the left side of a 16 bit
word, thus using both more time and memory than needed.

% The ix instruction set does have instructions designed for use from C
that do try to fake byte addressing.  Unfortunatly, most of the overhead
of the bit field insert/extract is still there.

-- 
Bob Larson	Arpa:	blarson@basil.usc.edu
Uucp: {uunet,cit-vax}!usc!basil!blarson
Prime mailing list:	info-prime-request%ais1@ecla.usc.edu
			usc!ais1!info-prime-request