Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!mhuxm!mhuxf!mhuxi!mhuhk!mhuxt!houxm!whuxl!whuxlm!akgua!gatech!seismo!rlgvax!hadron!jsdy
From: jsdy@hadron.UUCP
Newsgroups: net.lang.c
Subject: Re: SUN C compiler bug?
Message-ID: <343@hadron.UUCP>
Date: Sat, 29-Mar-86 02:49:57 EST
Article-I.D.: hadron.343
Posted: Sat Mar 29 02:49:57 1986
Date-Received: Tue, 1-Apr-86 07:16:57 EST
References: <5418@sri-spam.ARPA>
Reply-To: jsdy@hadron.UUCP (Joseph S. D. Yao)
Organization: Hadron, Inc., Fairfax, VA
Lines: 27
Keywords: shorts and ints.
Summary: Looks like a bug.  Tastes like a bug.  ...

In article <5418@sri-spam.ARPA> argv@sri-spam.ARPA (AAAARRRRGGGGv) writes:
>    char x;
>    for(x = 0; x < 128; x++)
>	putchar('x');
>on the sun, the variable x is signed and NOT converted to an int ...
>this program on a sun will produce nothing. On the vax, it will print 128 x's. 

It seems pretty clear that 128 is a numeric constant, not a character
constant.  Therefore, x should be converted to an int or unsigned int
(K&R 2.7, A.6.1; X3J11 3.1).  Which one (int or u_int) seems to be
irrelevant, given a character size >= 8 bits.  Unless the int size is
8 bits too, this behaviour is clearly incorrect.

>    int x;
>    for(x = 0; x < 4294967296; x ++)
>	putchar('x');
>this, too will also print nothing because 4294967296 is -1 and 'x' is
>signed.  Why is there a difference and who is "wrong"?

Here, x is clearly a signed integer.  The constant is too long to
fit into an int, and hence (as I've just learned!) is a long int ...
which is the same as an int on VAXen.  x is "promoted" to long int
(ha ha), and the two are compared, with the result you name.  All
kosher, per the standard(s).
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}