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!utah-cs!utah-gr!donn
From: donn@utah-gr.UUCP
Newsgroups: net.lang.c
Subject: Re: SUN C compiler bug?
Message-ID: <1710@utah-gr.UUCP>
Date: Fri, 28-Mar-86 22:29:20 EST
Article-I.D.: utah-gr.1710
Posted: Fri Mar 28 22:29:20 1986
Date-Received: Tue, 1-Apr-86 07:11:25 EST
References: <5418@sri-spam.ARPA>
Organization: University of Utah CS Dept
Lines: 28
Keywords: shorts and ints.
Summary: The VAX compiler you use is wrong too

The code in question:

	char x;
	for(x = 0; x < 128; x++)
		putchar('x');

The Sun compiler I use (Sun release 2.2) does indeed compile this
incorrectly, using a byte compare in the 'for' loop test.  But I
certainly wouldn't want my VAX to print 128 x's on my screen on the
basis of this program, as was claimed.  The local (4.3 BSD) VAX
compiler produces from this source a program that prints infinitely
many x's, because the char variable 'x' wraps around to -128 from 127
and thus never exceeds 128.  This program will print 128 x's only if
your VAX compiler treats char variables as being unsigned by default --
what kind of VAX compiler is that?

Mr. Argv asks:

	[S]hould the programmer know not to compare a size larger than
	or equal to the value of the type that would make a signed
	number negative[?] ...

If I understand this correctly, the answer is 'yes'.  Of course 'lint'
could find cases such as this and complain about them, as it already
complains about 'degenerate unsigned comparisons'.

Donn Seeley    University of Utah CS Dept    donn@utah-cs.arpa
40 46' 6"N 111 50' 34"W    (801) 581-5668    decvax!utah-cs!donn