Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!husc6!necntc!cullvax!drw
From: drw@cullvax.UUCP
Newsgroups: comp.lang.c
Subject: bytes don't fill words
Message-ID: <750@cullvax.UUCP>
Date: Mon, 26-Jan-87 12:31:50 EST
Article-I.D.: cullvax.750
Posted: Mon Jan 26 12:31:50 1987
Date-Received: Tue, 27-Jan-87 03:45:23 EST
Organization: Cullinet Software, Inc., Westwood, MA
Lines: 36

rbutterworth@watmath.UUCP (Ray Butterworth) writes:
> If it doesn't do so already, the ANSI C standard should explicitly
> state the following:
> 
> 1) BITS_PER_WORD%BITS_PER_BYTE need not necessarily be 0.
> 
> 2) Given TypeA and TypeB, such that sizeof(TypeA) > sizeof(TypeB)
> and sizeof(TypeA) % sizeof(TypeB) is 0, then for
> union {TypeA a; TypeB b[sizeof(TypeA)/sizeof(TypeB)];} u;
> assigning values to all the individual members of array u.b will
> in some well-defined implementation-defined manner assign values
> to all the bits of u.a (but not necessarily of u itself).

Not necessarily!  The bit-pattern in 'a' may not be a valid value for
its type.  The crux is "will ... assign values to all the bits of
u.a".  It may not wind up assigning a processable value to it.
(Consider that TypeB is 'char' and TypeA is 'float', and that the
implementation assigns floats by loading and storing a float register,
and that invalid float formats cause the processor to trap...)

Also, suppose that although TypeB is considered to have, say, 8 bits,
only 7 of them are actually used in any operation.  Suppose the
implementation exploits this fact--it doesn't bother setting the 8th
bit of the location when it is inefficient to do so.  Then, there is
no guarantee that all of the bits of 'u.a' will be set.

The moral of this is that point 2 isn't implied by point 1--it is a
complex and subtle constraint on the implementation that should
probably not be made.

Dale

-- 
Dale Worley		Cullinet Software
UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw
ARPA: cullvax!drw@eddie.mit.edu