From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <751d023752e74686a397bfd5fe76b9a7@chula.quanstro.net> Date: Tue, 28 Feb 2012 18:02:54 +0000 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [9fans] cast issue Topicbox-Message-UUID: 65947d44-ead7-11e9-9d60-3106f5b1d025 I never seem to get the right reply-to. But, that gives me a chance to add that: to guarantee sign-extension, using (char) isn't good enough, since it's not defined whether that's signed or unsigned. you need (schar) [signed char] as the cast. All Plan 9 compilers have char as signed. ---------- Forwarded message ---------- From: Charles Forsyth Date: 28 February 2012 17:53 Subject: Re: cast issue To: erik quanstrom =C2=A0 =C2=A0 =C2=A0 if((uint)p[1] >=3D 256) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 print("x\n"); =C2=A0 =C2=A0 =C2=A0 if((int)p[1] < 0) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 print("y\n"); those two are unsigned. p[1] is uchar. i think that one's the same under both unsigned-preserving and value-preserving rules. it's hard to tell with gcc, because it tosses a= way the code to test the impossible (which 6c and 8c could obviously do as well= ). (char)p[1] produces a sign-extending move byte, though. On 28 February 2012 13:44, erik quanstrom wrote: > however, the code generated is also curious. =C2=A0the cast to int is > ignored in the comparison.