Newsgroups: comp.os.minix
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: PC minix compiler bug/question
Message-ID: <1989Aug15.171204.22149@utzoo.uucp>
Organization: U of Toronto Zoology
References: <10363@fluke.COM>
Date: Tue, 15 Aug 89 17:12:04 GMT

In article <10363@fluke.COM> dcd@tc.fluke.COM (David Dyck) writes:
>	char p[1]= {-1};
>what does
>	(unsigned char) *p
>evaluate to?
>
>On the Minix ibm-pc c compiler it is -1 but all other systems seem to evaluate
>to 255...	What should the correct C compiler produce?

Well, let us trace through this.  The value in the char is -1 if "char" is
signed, 255 if it is unsigned.  [We will politely ignore the possibility
of non-two's-complement representations, and the possibility that a compiler
whose "char" is unsigned might object to -1.]  *p is an "int" value, since
"char" values promote to "int" immediately in C expressions, so that gives
us -1 for signed "char", 255 for unsigned "char".  Then we cast to "unsigned
char", which gives us 255 either way by X3J11 conversion rules.  Then finally
we do the implicit expansion to "int" again, giving 255.  Older compilers
implementing signedness-preserving rules might expand "unsigned char" to
"unsigned int", but again we get 255.

There just isn't any way that an "unsigned char" should ever expand to a
negative value; something is wrong with the Minix compiler.
-- 
V7 /bin/mail source: 554 lines.|     Henry Spencer at U of Toronto Zoology
1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu