Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!think!ames!oliveb!sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: comp.lang.c Subject: Re: Was that a Sun bug? Message-ID: <23443@sun.uucp> Date: Tue, 14-Jul-87 16:28:26 EDT Article-I.D.: sun.23443 Posted: Tue Jul 14 16:28:26 1987 Date-Received: Thu, 16-Jul-87 07:07:40 EDT References: <1429@cci632.UUCP> Sender: news@sun.uucp Lines: 31 Keywords: bug comparison Sun Parallel > Anyhow, is this a bug, or am I crazy? Is this a Parallel bug, or does it > exist on Sun 4.2 systems too? From the diagnostics issued by a SunOS 3.2-vintage compiler: "foo.c", line 8: warning: constant 1026 is out of range of char comparison "foo.c", line 8: warning: value coerced to 2 for bug compatibility "foo.c", line 8: warning: do not expect this coercion in release 4.0 So yes, it is a bug. I guess somebody complained because their incorrect code ceased to "work" when the bug was fixed. The Parallel "guru" is right in the sense that K&R, for whatever reason, does not explicitly say that "the usual arithmetic conversions" are performed for relational and equality operators, but it does list them explicitly for other classes of operators. I don't know whether this was done intentionally, to indicate that some other conversions should be performed, or whether it was just an accidental omission. Clearly, *some* conversions must be performed, and the usual arithmetic conversions would seem to make sense; *narrowing* one of the operands doesn't seem to make much sense at all. (The compiler should be smart enough to do a byte comparison *when it would give the proper results*.) The current ANSI C draft, however, *does* say that the usual arithmetic conversions are performed, which makes more sense; as you noted, performing the UNusual arithmetic conversions that our compiler was doing violates the Principle of Least Surprise. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com