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