SUN C compiler bug?

[AAAARRRRGGGGv]

Consider the following routine on the sun:

    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.  So, running 
this program on a sun will produce nothing. On the vax, it will print 128 x's. 

Bug with the sun? Maybe...
1) should 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
(as above) or 2) should the compiler know that all constants should be
taken as literal (or, the assembler should do this) and compared as
such?

Whichever you think should be the "way", remember that the vax has the
same "bug" (?) with intergers:

    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"?   well, arguing
for the second example above says that suns assembler is wrong because it
creates code that moves a byte into a register and does a cmpb
(compare byte) intruction where as they should do a cvtbl (convert a
btye to long) and then move into a register and cmpl (compare long).

Supporting argument 1) says that what I just said (above) will fix the
problem with bytes or shorts, but not ints, and that's right. Even on a
vax, you have to make sure that you don't compare with potentially signed
values so the programmer is responsible and should not have created either
of the two cases above.

Let's throw another log into the fire.  Compile the first example with
the -O (code optimizer) flag on the sun. You'll find that a single 'x' 
is printed and nothing more. It actually does one round inside the for loop!
(The vax doesn't do this.) It is definitely a bug when the optimizer
produces different output than without the optimizer.