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