Path: utzoo!attcan!uunet!oddjob!ncar!ames!mailrus!uflorida!novavax!proxftl!bill
From: bill@proxftl.UUCP (T. William Wells)
Newsgroups: comp.lang.c
Subject: Re: Puzzle on unsigned promotions
Summary: what K&R actually says
Message-ID: <460@proxftl.UUCP>
Date: 13 Jul 88 03:04:49 GMT
References: <736@vsi.UUCP> <12251@mimsy.UUCP> <565@unh.UUCP> <28@cybaswan.UUCP>
Distribution: comp
Organization: Proximity Technology, Ft. Lauderdale
Lines: 36

In article <28@cybaswan.UUCP>, iiit-sh@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.