🚀 go-pugleaf

In article <WALD.96Feb24131532@woodpecker.lcs.mit.edu>, wald@theory.lcs.mit.edu (David Wald) writes:
>During a recent recurrence of the perennial "how big is an int"
>discussion on comp.lang.c.moderated, I described a freestanding C
>implementation I'd dealt with in which, as in some other word-based
>implementations, sizeof(char) == sizeof(long) == sizeof(float).
>However, one quirk of this architecture was that not all
>interpretations of a memory word could see all bits.  In particular,
>though integral types and floats each took one word, a float used 8
>more bits than the integral types.  When a word was used in integral
>operations, the lower 8 bits were invisible and harmless.  Thus you
>could have two sections of memory which could be distinguished when
>viewed through float*'s but not when viewed through char*'s.
>Can such an implementation be ANSI-conformant?

At present, I think it can.  As written, the standard does not say whether
types char, signed char, and unsigned char are required to use all bits of
the storage they occupy in determining the values they represent.  Bits
not used are now called "holes" (which is not what they were called by
the base document K&R-I).

Rumor has it that Technical Corrigendum 2 will change the standard so that
unsigned char cannot have any holes.  Signed char will still be allowed to
have holes, and char will still have to behave either as unsigned char (no
holes) or as signed char (identical holes).

>The basic argument against, presented by Tanmoy Bhattacharya, is that
>memory compare, and possibly memory copy functions, can't be implemented
>in a portable fashion if two dissimilar regions of memory can't be
>distinguished by comparing them char-wise.

Is that really what he said?  I'm sure Mr. Bhattacharya knows many parts
of the standard which cannot be implemented in a portable fashion.  Every
implementation has to provide some degree of portability to some kinds of
programs -- that is what the standard requires -- but an implementation
itself does not port so easily.  So, what is one more minor grunge?

>(I'm unsure about the memory copy, since I've forgotten whether the
>implementation actually preserved the hidden 8 bits when you copied a char.)

If you assign one char to another using an assignment operator, it doesn't
have to do so.  (Except of course that after TC2, if you use unsigned chars,
then there can't be hidden bits any more.)

If you use memcpy or possibly if you play tricks with union types, you can
force it to copy all the bits.
--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer