Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!husc6!rutgers!clyde!watmath!rbutterworth From: rbutterworth@watmath.UUCP (Ray Butterworth) Newsgroups: comp.lang.c Subject: Re: is it really necessary for character values to be positive? Message-ID: <4098@watmath.UUCP> Date: Tue, 23-Dec-86 11:22:38 EST Article-I.D.: watmath.4098 Posted: Tue Dec 23 11:22:38 1986 Date-Received: Wed, 24-Dec-86 00:17:22 EST References: <39@houligan.UUCP> Organization: U of Waterloo, Ontario Lines: 35 In article <39@houligan.UUCP>, dave@murphy.UUCP writes: > In short, it doesn't look to me like there is any good reason to require > characters to be represented as positive values. Or have I overlooked > something really basic? Consider the following: char str[5]; int i; i=getchar(); str[0]=i; if (i!=str[0]) printf("Is this possible?"); if (isupper(i) && !isupper(str[0])) printf("How about this?"); The answer is that yes, it is possible when getchar() is allowed to return characters that have the upper bit on, on compilers that sign extend. If the character is 0xF0 say, "i" will be assigned 0xF0, but str[0] will have the value 0xFFFFFFF0, and the comparison will fail. Similarly, many functions such as isupper() will behave incorrectly since they aren't defined to work on negative arguments. If ANSI were to define getchar() to return a value that is sign extended on machines that sign-extend chars, and define functions such as isupper() to accept such arguments, I think it would solve most problems of sign-extension and 8-bit character sets. It probably wouldn't break any existing source code either (except for code that stupidly ignores the EOF manifest and uses an explicit value). > > 4. The value 255 can't be used because it may look like EOF on some systems. The only requirement on EOF is that it be a negative int. If the implementors make it say, (-12345), it won't be confused with any character, with or without sign extension.