🚀 go-pugleaf

In article <4gr3d1$dca@usenet.pa.dec.com>
diamond@tbj.dec.com (Norman Diamond) writes:
<snip>
ND: Rumor has it that Technical Corrigendum 2 will change the standard so that
ND: unsigned char cannot have any holes.  Signed char will still be allowed to
ND: have holes, and char will still have to behave either as unsigned char (no
ND: holes) or as signed char (identical holes).

What happens to the requirement that positive signed integral values
have to have the same representation as the corresponding unsigned
integral value? Coupled with the requirement of pure binary
representation (I am not sure what `pure binary' means: assuming it
means that only one bit can represent the sign), it seems to say that
if unsigned char can't have holes, neither can signed char unless
whether a certain bit contributes to the value or not depends on the
sign bit; I assume such `holes' are allowed?

ND: 
ND: >The basic argument against, presented by Tanmoy Bhattacharya, is that
ND: >memory compare, and possibly memory copy functions, can't be implemented
ND: >in a portable fashion if two dissimilar regions of memory can't be
ND: >distinguished by comparing them char-wise.
ND: 
ND: Is that really what he said?  I'm sure Mr. Bhattacharya knows many parts
ND: of the standard which cannot be implemented in a portable fashion.  Every
ND: implementation has to provide some degree of portability to some kinds of
ND: programs -- that is what the standard requires -- but an implementation
ND: itself does not port so easily.  So, what is one more minor grunge?
ND: 

No, that was not the argument. I was assuming that the rumored TC2
interpretation will be adopted. The argument is that in 

float x, y;
unsigned char *xx=(void*)&x, *yy=(void*)&y;

copying (or comparing) sizeof(float) unsigned chars from xx to yy must
manage to copy (or compare) x from y.

The suggestion to post to comp.std.c was precisely because this was a
rumor, and people in this group are more likely to know whether I have
got the gossip right :-)

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

Whether or not `char' can have holes, if there are say two
representations of 0 (sign-magnitude / one's complement etc.) a copy
of char can change one representation to the other.

ND: 
ND: If you use memcpy or possibly if you play tricks with union types, you can
ND: force it to copy all the bits.

This was a free-standing implementation, and memcpy may be absent. (In
a hosted implementation, as all read/write is done as if through
getc/putc which handles unsigned char values, and binary files written
out must be read back unchanged, the situation is impossible).

Cheers
Tanmoy
--
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]