thanks for "down" answers

[Piercarlo Grandi]

In article <685 at auspex.UUCP> guy at auspex.UUCP (Guy Harris) writes:

	[ good reminder on why the result of getchar(3) has int length ]

    On a machine with signed "char"s, and 8-bit bytes, a "char" can have a
    value in the range -128 to 127.

This is exactly true.

    This means that if you read a character from the file with the hex value
    0xFF - which is "y with a diaresis" in ISO Latin #1, so even in a pure
    text file you can have such a character ...

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... So, EOF == -1 is guaranteed to work
indeed.  In other words, getchar(3) is not a "getbyte()".

    ... - it will look just like an EOF.

Supposedly not, because getchar(3) returns an "int", not a "char" that is
widened to an "int".

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.

[2] In dpANS C you can explicitly control whether a "char" is signed or not,
    so there is no problem either.

[3] In any case, the result of getchar(3) is an "int", not a "char".

Admittedly, the ice is not thick here (pun on K&R :->). If one wants absolute
safety in reading *bytes* (not characters), one must use fread(3) (ugh!).
-- 
Piercarlo "Peter" Grandi			INET: pcg at cs.aber.ac.uk
Sw.Eng. Group, Dept. of Computer Science	UUCP: ...!mcvax!ukc!aber-cs!pcg
UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)