chris@mimsy.UUCP (Chris Torek) (05/02/88)
In article <375@m3.mfci.UUCP> root@mfci.UUCP (SuperUser) writes: >No, these two programs are not equivalent. [They were equivalent. The comparison was |unsigned char| != -1, which ---provided |char| is shorter than |int|---is indeed always true, in both the existing sign preserving system and in the value preserving system in the dpANS.] >When comparing an unsigned [integer] to a signed integer, the signed >integer is first cast to unsigned (which results in no change in the >bit pattern), then the comparison is performed. With the insertion I have made (which was implied, but given dpANS rules one must be explicit), this is correct. >since octal and hex constants are signed in C, In K&R. In dpANS C, some octal and hex constants are unsigned, as are some integer constants. >... People are often surprised by the fact that an expression like >(u > -1) is always false when u is unsigned, since the -1 is first >cast to unsigned, whereupon it becomes the largest possible unsigned. Again, this is correct in both systems, with the proviso that |u| is |unsigned int|, not |unsigned char| or |unsigned short|. Under dpANS rules, however, if |u| is |unsigned char| and |char| is shorter than |int|, it will be always true; if |u| is |unsigned short| the test will be either always true or always false, depending on the size of |short| vs |int|. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
root@mfci.UUCP (SuperUser) (05/03/88)
Expires: Followup-To: Distribution: Keywords: In article <11304@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >[They were equivalent. The comparison was |unsigned char| != -1, which >---provided |char| is shorter than |int|---is indeed always true, in both >the existing sign preserving system and in the value preserving system in >the dpANS.] Oops, I hadn't noticed that the routine was returning an unsigned char, I only noticed the unsigned. Yes, assuming chars are shorter than ints then an unsigned char, when zero-padded out to a full int, will never have the same bit pattern as -1. (I should add that I've always thought that C routines which return chars or shorts should be avoided, and that such data types should only be used for arrays and structure members, since C prefers to deal with full size integers, and using chars and shorts will at best cost you a bunch of useless sign extensions/zero fills and truncations, and at worst will cause unexpected results.)