Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!mordor!sri-spam!ames!ucbcad!ucbvax!decvax!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: comp.lang.c,comp.std.internat Subject: Re: draft ANSI standard: one change that would *really* help Europe Message-ID: <10429@sun.uucp> Date: Sun, 14-Dec-86 03:06:03 EST Article-I.D.: sun.10429 Posted: Sun Dec 14 03:06:03 1986 Date-Received: Tue, 16-Dec-86 01:48:27 EST References: <1382@hoptoad.uucp> <8322@lll-crg.ARpA> <2221@eagle.ukc.ac.uk> <137@piaget.UUCP> Organization: Sun Microsystems, Inc. Lines: 26 Summary: Chars are unsigned on the 3B2! Xref: mnetor comp.lang.c:380 comp.std.internat:46 > I believe that the 3B2, to pick an example, places char in the high order > byte of the register. You may believe that, but it's not the case. It's also completely irrelevant; the C language states quite precisely what happens in the case cited, both in the case where "char" is signed and in the case where "char" is unsigned. The implementation can put the character into any byte it wants, as long as it behaves the way K&R, or the ANSI C spec, say it should. > If you test one for equality with (int) -1 you will never pass the test. That's because characters are UNsigned on the 3B2. > As for the above construct working on any machine with signed char, I doubt > that it will work on the 3B2. See above. The construct doesn't work on the 3B2 because it *isn't* a machine with signed char. The above construct *will* "work", in some sense, on any C implementation with signed "char". It *still* won't work correctly; on a machine with signed "char" and 8-bit bytes, a byte with the value 0xff will be sign-extended to -1, and thus will compare equal to EOF even though it's a perfectly legitimate datum. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)