Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!amdcad!cae780!hplabs!hpcea!hpda!hpclla!mar From: mar@hpclla.UUCP Newsgroups: comp.lang.c Subject: Re: bug re unsigned to signed conversion? Message-ID: <4400001@hpclla.HP.COM> Date: Mon, 8-Jun-87 17:55:14 EDT Article-I.D.: hpclla.4400001 Posted: Mon Jun 8 17:55:14 1987 Date-Received: Sat, 13-Jun-87 04:39:37 EDT References: <4626@columbia.UUCP> Organization: Hewlett-Packard CLL Lines: 34 >/ hpclla:comp.lang.c / eppstein@garfield.columbia.edu (David Eppstein) / 12:39 pm May 24, 1987 / > The following program prints both messages. I would expect it to print >neither, but at least the second message shouldn't happen. The >generated C code for the two lines is essentially identical; no doubt >the second line and probably the first should have generated a cast to int. >This is on a Vax running 4.3; I don't know what version C++. >It occurred in a real example and took me much grief to track down. >I'm not convinced the C compiler is correct, which is why I'm also cross >posting to comp.lang.c. >#include >int a = -1; >unsigned b = 2; >inline int conv() { return b; } >main() >{ > if (a > b) cout << "(int) -1 > (unsigned) 2 ???\n"; > if (a > conv()) cout << "(int) -1 > (int) (unsigned) 2 ????????\n"; >} -- I compiled this useing the 1.1 version of C++. The C code generated is incorrect, you were right in assuming that the C++ compiler should generate a cast to int for the inline construct. The C compiler is correct in how the code is handled: By ordinary promotion rules, if one operand is unsigned then the other is converted to unsigned and the expression result is unsigned. Hence, in the expression 'a' is converted to unsigned before the comparison and the result is true: (unsigned) -1 > (unsigned) 2. The C code generated for the second expression is identical except for an extra set of parens around the return value 'b', which are insignificant in this case.