thanks for "down" answers

[Guy Harris]

>This is not entirely accurate. Classic C says that chars must be able to
>represent the machine's character set, whose character codes are assumed to
>be *positive*:  '... it is guaranteed that a member of the standard character
>set is non negative'. So a "char" variable may indeed represent negative
>values, but they cannot be characters...

Err, umm, no, they cannot be characters in the "standard character set".
This does not mean that they are not "characters"; I suspect some
speaker of whatever language uses "y with a diaresis" is likely to be
a{mused|nnoyed} by a claim that it is not a character....

>    ... - it will look just like an EOF.
>
>Supposedly not, because getchar(3) returns an "int", not a "char" that is
>widened to an "int".

The issue being discussed was why

	char c;

	if ((c = getchar()) != EOF)

is a Bad Thing regardless of whether "char"s are signed or not; on a
machine where "char"s are signed, a "y with a diaresis" character *will*
look like an EOF *in the "if" clause in question", because the "int"
result of "getchar" - having the value 255 - will get stuffed through
the "char-sized knothole" represented by "c", and will come out the
other end looking like -1, i.e. EOF, which tends to look like EOF....

>There are two points here:
>
>[1] In Classic C *characters* (as opposed to "char" values) can only be non
>    negative. There is no problem even when "char" is signed by
>    default.

Err, umm, I'm sure you're tired of having this pointed out to you, but
you need to provide a reference that demonstrates that "character" and
"member of the *standard* character set" ("italics" mine) are
equivalent; just because you *interpreted* it as meaning that doesn't
mean that *was* what it meant.  If you don't like having it pointed out
to you, provide more references; it's really that simple....