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)