Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site valid.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!pesnta!valid!pete
From: pete@valid.UUCP (Pete Zakel)
Newsgroups: net.lang.c
Subject: Re: SUN C compiler bug?
Message-ID: <215@valid.UUCP>
Date: Fri, 4-Apr-86 18:20:32 EST
Article-I.D.: valid.215
Posted: Fri Apr  4 18:20:32 1986
Date-Received: Tue, 8-Apr-86 05:22:14 EST
References: <5418@sri-spam.ARPA> <852@koudai.uucp>
Organization: Valid Logic, San Jose, CA
Lines: 25

> I know a similar bug(?) on the Sun C compiler.
> Consider the code something like:
> 
> 	printf("%d\n", (any_expr, 257)) ;
> 		/*
> 		 * Of course, it does not mean printf("%d\n", any_expr, 257) ;
> 		 * (any_expr, 257) is a comma expression
> 		 */
> 
> This should generate output '257' (it is on Vax), but it actually outputs
> '1' on any version of Sun as long as I know (release 1.2, 2.2, 3.0).
> It interpretes the last component of comma expression as a singed character,
> if it is an integer constant.  This is a bug, isn't it?
> ----
> Hiroshi Tachibana

I tried this with our C compiler, and it works the way Hiroshi describes.  I
assume it is a problem with any PCC based C compiler.  Comments, anyone?
(Oh, and I assume you mean "signed" character, as that is the way mine
treated it.  When I changed the value from 257 to 254, the program output
'-2' - which, when you think about it, is pretty much of a 'burn', isn't it?
By the way, I got the program to give correct results by changing "257" to
"(unsigned) 257")
-- 
-Pete Zakel (..!{hplabs,amd,pyramid,ihnp4}!pesnta!valid!pete)