Puzzle on unsigned promotions

[T. William Wells]

In article <28 at cybaswan.UUCP>, iiit-sh at cybaswan.UUCP (s.hosgood) writes:
> I found a similar problem to the above-mentioned occurs with assigning
> constants. K&R don't really seem to specify if they consider a constant to
> be signed or unsigned. However, they *do* seem to say that constants behave
> like 'int's unless they are too long to be 'int', in which case they magically
> become 'long'. I once actually had to write a compiler from scratch, and the
> assignment:
>
>       long    temp;
>
>       temp = 0xFFFF;
>
> ..gave rise to the question of what to do? - treat the constant as an 'int'
> of -1 and sign-extend, or treat it as an unsigned bit-pattern and just
> zero-fill it? I chose the latter, but I never found a satisfactory answer
> from K&R!

Quoting K&R from 2.4.1, p.180:

"An integer constant is...

...A decimal constant whose value exceeds the largest signed
machine integer is taken to be long; an octal or hex constant
which exceeds the largest unsigned machine integer is likewise
taken to be long."

As far as I know, K&R does not speak of unsigned constants; that
version of C simply does not have them.

Assuming two's complement and two byte integers, 0xFFFF
represents the integer constant whose bit pattern is 0xFFFF,
i.e., the value -1. So, counter-intuitive or not, that temp =
0xFFFF; ought to assign -1 to temp. I'm not saying that I think
that is the proper language definition; only that a reading of
K&R that does not include one's own wishing does not support
unsigned constants or the assignment of 0xFFFF to temp.