getchar() and EOF confusion

[jameskuyper]

(e-mail address removed) wrote:
....

Not in C. In C, 0xFFFFFFFF is just a different way of writing the same
value as 2147483647 - the only difference is that 0xFFFFFFFF might
have an unsigned type, while 2147483647 must have a signed type.
0xFFFFFFFF never has the meaning "-1". It can be converted to an int,
and if 'int' is a 32-bit 2's complement type the result of that
conversion will probably be -1, but that doesn't mean that 0xFFFFFFFF
is -1.

I used the wrong power of 2, of course. Replace 2147483647 with
4294967295 in all locations in that paragraph. Argh!

 

[David Thompson]

(e-mail address removed) wrote:
...

I used the wrong power of 2, of course. Replace 2147483647 with
4294967295 in all locations in that paragraph. Argh!

In C89 unsuffixed decimal goes signed int, signed long, unsigned long.
For the common case of L32, that literal (with value 2 up 32 less 1)
is UL. That isn't relevant to your argument, though. However,
unsuffixed hex or octal CAN be signed; they go SI, UI, SL, UL.
For L32 0x(eight F) is UL, and as you say equal to (UL)-1,
but for L>32 it's SL (and large positive != -1) unless I=32 in which
case it's (representable in) UI (and again equal to converted -1).

In C99 unsuffixed decimal stays signed. Unsuffixed octal or hex still
goes through both signed and unsigned; for most machines with
power-of-2 sizes (S=U) the choice will land on unsigned, but other
architectures are permitted.

It is always true, as you say, that the C literal 0x(eight F) (as
opposed to the bit representation) is never actually (int)-1; it is
*sometimes* true that it converts to and/or from (int)-1. Even when it
works, it is less clear and obvious than writing -1 to mean -1.

- formerly david.thompson1 || achar(64) || worldnet.att.net