Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!hou3c!hocda!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!sdcrdcf!sdcsvax!dcdwest!ittvax!decvax!cca!ima!haddock!lee
From: lee@haddock.UUCP
Newsgroups: net.unix-wizards
Subject: Re: ((c = getc(stdin)) == EOF) retractio - (nf)
Message-ID: <183@haddock.UUCP>
Date: Fri, 15-Jun-84 02:42:14 EDT
Article-I.D.: haddock.183
Posted: Fri Jun 15 02:42:14 1984
Date-Received: Wed, 13-Jun-84 01:37:33 EDT
Lines: 32

#R:basser:-31000:haddock:16800015:000:1441
haddock!lee    Jun  7 21:55:00 1984

A couple of people have asserted that on machines without "signed chars"
(that is, single byte values that can be negative), the C implementation
of "char" and "unsigned char" are equivalent.  This is not true, do to
a subtlety in the definition of type coercions in C.

Note that "char" is part of the sequence char-short-int-long, whereas
"unsigned char" is part of the sequence uchar-ushort-uint-ulong, where the
second sequence has the property "unsigned".  During coercions, unsigned
chars are extended to unsigned whereas chars are extended to int (by zero
extension or sign extension, whichever is appropriate).

Once extended, the expression retains its "unsigned" attribute, so that
higher level expressions are performed as unsigned operations.  Here is
an example (assuming a 32-bit machine with positive characters):

	char foo=1; if ( (-1 | foo) < 0 ) printf("-1 is negative");

	unsigned char foo=1; if ( (-1 | foo) > 0 ) printf("-1 is positive");

Both printf's should print; the first is obvious, but the second prints
because foo is extended to unsigned, -1 is then coerced to unsigned to
be combined with foo, the result is unsigned and therefore >= 0.

I do not have a survey of compilers to determine whether or not this issue
is handled correctly in them.  It can, however, result in terribly erroneous
code if a compiler treats char and unsigned char the same, especially in the
presence of >> operators.

						-- Lee