Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.lang.c
Subject: Re: bytes don't fill words
Message-ID: <5572@brl-smoke.ARPA>
Date: Wed, 28-Jan-87 01:29:17 EST
Article-I.D.: brl-smok.5572
Posted: Wed Jan 28 01:29:17 1987
Date-Received: Thu, 29-Jan-87 05:48:53 EST
References: <4603@watmath.UUCP> <815@cartan.Berkeley.EDU>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: comp
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 22

>>1) BITS_PER_WORD%BITS_PER_BYTE need not necessarily be 0.

I am afraid this confusion is due to my mistake in an earlier posting.
Early in the draft proposed standard we guarantee that all objects are
collections of bytes.  This may mean that a byte has to be bigger than
one might want; for example on the (hypothetical) MINSK-3B the word
size might be 17 bits, which is prime, which means the smallest C
object (currently, a char) would have to be some multiple (1) of 17 bits.
It isn't allowed to make chars 8 bits on the MINSK-3B.  Sorry.

>>3) The behaviour of functions memcmp(), memcpy(), etc. is
>>undefined if the two arguments are not pointing at similarly
>>aligned data.

I believe the draft proposed standard needs to be beefed up a bit
to guarantee that a pointer conversion produce pointer to the
"lowest" portion of the object pointed to by the original pointer
(the one that is being operated on to produce a new pointer).
With this guarantee, the mem*() functions are safe.  However,
implementors should note that there can't be any "holes" in structs
that are unsafe to touch (i.e., no access violation for touching
uninitialized locations in the holes).