Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!bellcore!ulysses!allegra!mit-eddie!think!harvard!seismo!mcvax!kddlab!koudai!tachi
From: tachi@koudai.uucp (Hiroshi Tachibana)
Newsgroups: net.lang.c
Subject: Re: SUN C compiler bug?
Message-ID: <852@koudai.uucp>
Date: Sun, 30-Mar-86 15:02:29 EST
Article-I.D.: koudai.852
Posted: Sun Mar 30 15:02:29 1986
Date-Received: Wed, 2-Apr-86 20:57:20 EST
References: <5418@sri-spam.ARPA>
Reply-To: tachi@koudai.UUCP (Hiroshi Tachibana)
Organization: Tokyo Institute of Tech., Dept. of Computer Science, Japan
Lines: 28

In article <5418@sri-spam.ARPA> argv@sri-spam.UUCP writes:
> 
>     char x;
>     for(x = 0; x < 128; x++)
> 	putchar('x');
> 
> You would expect to have 128 x's printed on your screen.  but,
> on the sun, the variable x is signed and NOT converted to an int
> as it is on the vax version of the 4.2 UNIX C compiler.

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
Dept. of C.S., Tokyo Institute of Technology
UUCP: ...!{hplabs,seismo,ihnp4}!kddlab!koudai!tachi