How to use toupper()

Doug Gwyn gwyn at smoke.BRL.MIL
Sat Jan 21 03:38:56 AEST 1989


In article <23156 at watmath.waterloo.edu> rbutterworth at watmath.waterloo.edu (Ray Butterworth) writes:
>If 'C' is any character that sign extends, the switch won't work.

In Standard C it will work for all 'C' in the required source
character set, which are required to have nonnegative values as
"chars", which match the character-constant integer values.

Sign extension of "chars" has ALWAYS been an issue for portable
C programming, and there is no way to fix that in the Standard
other than by outlawing signed implementation of "char", which
the Committee has repeatedly declined to do.

>Much of this was mentioned to the Committee.
>e.g. Letter P04 to the Second Public Review contained: ...

And letter L181 which was responded to in the third formal public
review repeated the point, which I summarized as:

	<ctype.h> macros should be made safe for "signed char"
	arguments.

The X3J11 response was:

	The Committee has voted against this idea.

	"char" arguments can always be cast to "unsigned char"
	type before calling a <ctype.h> function.  Indeed, since
	one cannot distinguish in classic signed "char"
	implementations between EOF (with value -1) and the
	8-bit char '377', whenever there might be a '377' value
	for a "char" the argument *must* be cast to an "unsigned
	char" for such implementations.

>+  ... there certainly can't be any existing code that depends on
>+  the described behavior.

But there is a LOT of code that does.  As you note, implementations
in environments with characters with high bits set are advised to
to implement plain "char" as if it were unsigned.

>Drop that requirement and say that they are only defined to work on
>values that can be returned by getchar().

What's the point?  getchar() can return ANY byte value, or EOF.  The
proposed Standard already requires that the argument to a ctype-
function be representable as an "unsigned char" or equal the value EOF.

You've tried at least twice now to convince X3J11 to change this part
of the specification, and you haven't convinced them.  Why carry on
about it here?



More information about the Comp.std.c mailing list