Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!gatech!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.lang.c
Subject: Re: SUN C compiler bug?
Message-ID: <714@umcp-cs.UUCP>
Date: Sun, 6-Apr-86 01:18:22 EST
Article-I.D.: umcp-cs.714
Posted: Sun Apr  6 01:18:22 1986
Date-Received: Wed, 9-Apr-86 07:04:38 EST
References: <5418@sri-spam.ARPA> <852@koudai.uucp> <215@valid.UUCP>
Reply-To: chris@maryland.UUCP (Chris Torek)
Organization: University of Maryland, Dept. of Computer Sci.
Lines: 27

In article <215@valid.UUCP> pete@valid.UUCP (Pete Zakel) writes:
>I tried [printf("%d\n", (0, 257)) and it failed, printing `1'].  I
>assume it is a problem with any PCC based C compiler.

Not so:  On a 4.3-beta Vax compiler, this will print 257.  You
can get around the bug on Suns by forcing the constant to be `long':

	f((0, 257L));

passes 257 to `f'.

This may be related to another bug, where

	f((int)(char)(const));

will not sign extend the constant `const' (variables are properly
sign extended).  Indeed, that problem also goes away if `const' is
a long constant, or if you use

	f((int)(char)(int)(const));

It appears to be the result of an improperly executed attempt at
improving the code generated by small integer constants.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu