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