SARGON@UMass.BITNET (10/12/86)
> From: imagen!turner@ucbvax.Berkeley.EDU (D'arc Angel) > Subject: bug in megamax C > Message-Id: <609@imagen.UUCP> > > here's a cute bug in megamax C: > > int c; > > while((c = getchar()) != EOF) { > . > . > . > } > > works fine but: > > unsigned char c; > > while((c = getchar()) != EOF) { > . > . > . > } > > loops infinately, the problem is that megamax generates the > following code: > > AND #0xff,D0 ;D0 has the result of getchar > CMP #-1,D0 ;ooppsss should be CMP.B > > ah well I pulled out my copy of the C bible (K&R) and I found the following quote: On a machine which does not do sign extension, c is always positive because it is a char, yet EOF is negative. As a result, the test always fails to avoid this, we have been careful to use int instead of char for any variable which holds a value returned by getchar. The real reason for using int instead of char is not related to any questions of possible sign extension. It is simply that getchar must return all possible characters (so that it can be used to read arbitrary input) and, addition, a distinct EOF value. Thus its value cannot be represented as a char, but must instead be stored as an int. (page 40) This brings us to EOF. If EOF is defined in such a way that it is represented as an integer, then you go pp 183-184 to find that "A character or a short integer may be used wherever an integer may be used. In all cases the value is converted to an integer." The section on unsigned is a little vague as it only addresses integers and their conversion to long, but the basic principle is to pad left with zeros. Im no expert on C; Ive not used it for that long but I think that the bug is in the example, not the compiler. -Steve ----------- K&R is "The C Programming Language" written by Brian W. Kernighan and Dennis M. Ritchie, copyright 1978, published by Prentice-Hall, INC, Englewood Cliffs, New Jersey 07632. ~~~~~~~~~~~ Sargon@Umass.BITNET Sargon%Umass.BITNET@WiscVM.Wisc.EDU