bytes don't fill words

gwyn at brl-smoke.UUCP gwyn at brl-smoke.UUCP
Wed Jan 28 16:29:17 AEST 1987


>>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).



More information about the Comp.lang.c mailing list