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.