cmt@myrias.UUCP (Chris Thomson) (09/23/86)
In article <3422@umcp-cs.UUCP> Chris Torek writes: > Storage Type Expression Equivalent > ------------ --------------------- > char int > unsigned char unsigned int > short int > unsigned short unsigned int > int int > unsigned int unsigned int > long long > unsigned long unsigned long > float double > double double > pointer pointer It is interesting to note that K&R does not say that unsigned char or unsigned short get promoted to unsigned int; it says that they get promoted to integer (on page 183), which is a bit vague. Harbison & Steele says very clearly what is said above. The ANSI Draft (1986.07.09 version) says very clearly that unsigned char and unsigned short are promoted to int, since the values can all be represented in an int (assuming sizeof(int) is greater than sizeof(short), which is usually true). What to do? Frankly, I prefer the ANSI approach, but it does represent a silent change from what H&S (and Chris Torek) perceive to be standard practice. For some reason, it is not flagged as such in the rationale document; it isn't even discussed there. -- Chris Thomson, Myrias Research Corporation alberta!myrias!cmt 200 10328 81 Ave, Edmonton Alberta, Canada 403-432-1616
tom@hcrvx1.UUCP (Tom Kelly) (09/26/86)
In article <271@myrias.UUCP> cmt@myrias.UUCP (Chris Thomson) writes: > ... The ANSI Draft (1986.07.09 version) says >very clearly that unsigned char and unsigned short are promoted to int, >since the values can all be represented in an int (assuming sizeof(int) >is greater than sizeof(short), which is usually true). > >What to do? Frankly, I prefer the ANSI approach, but it does represent a >silent change from what H&S (and Chris Torek) perceive to be standard >practice. For some reason, it is not flagged as such in the rationale >document; it isn't even discussed there. This change was the subject of long and hard investigation and debate in the ANSI C (X3J11) committee. It is a quiet change from common practice in (for example) PCC-based compilers, but there are other implementations that do promote unsigned char and unsigned short to int. The decision was not made lightly - the debate went on for at least a year. The issue is discussed at length in the Rationale (86-099 7 July 1986), in 3.2 Conversions (pp. 32-33). In particular, on p 33: QUIET CHANGE A program that depends upon unsigned preserving arithmetic conversions will behave differently, probably without complaint. This is considered the most serious semantic change made by the Committee to a widespread current practice. Tom Kelly (416) 922-1937 Human Computing Resources Corp. {utzoo, ihnp4, decvax}!hcr!hcrvx1!tom
rbutterworth@watmath.UUCP (Ray Butterworth) (09/26/86)
> It is interesting to note that K&R does not say that unsigned char or > unsigned short get promoted to unsigned int; it says that they get promoted > to integer (on page 183), which is a bit vague. Harbison & Steele says > very clearly what is said above. The ANSI Draft (1986.07.09 version) says > very clearly that unsigned char and unsigned short are promoted to int, > since the values can all be represented in an int (assuming sizeof(int) > is greater than sizeof(short), which is usually true). > > What to do? Frankly, I prefer the ANSI approach, but it does represent a > silent change from what H&S (and Chris Torek) perceive to be standard > practice. For some reason, it is not flagged as such in the rationale > document; it isn't even discussed there. There is one major problem with the ANSI proposal. When doing comparisions, if the two types aren't identical after the usual conversions and one of them is unsigned, the comparison is done as unsigned. e.g. "(-1) >= ui" for all unsigned ints ui. (In particular, "(-1)>sizeof(anything)" is always true if size_t is unsigned long or unsigned int.) This can be somewhat surprising, but one can learn to live with it once the principle is understood. The real problem occurs with shorts and unsigned shorts. Consider the comparison "neg1>=us", where "neg1" is an int with value -1 and "us" is any unsigned short. If sizeof(unsigned short)<sizeof(int), the "us" is promoted to an int and the comparison is done between ints and the result is always false. But if sizeof(unsigned short)==sizeof(int), "us" is promoted to unsigned int, "neg1" is converted to unsigned int, and the comparison is always true. Now this is not only surprising, it means that comparing an unsigned short with an int (or a constant) can give different results depending upon the machine one is using. How many people are going to keep this in mind while writing their code?
brett@wjvax.UUCP (Brett Galloway) (09/26/86)
In article <271@myrias.UUCP> cmt@myrias.UUCP (Chris Thomson) writes: >In article <3422@umcp-cs.UUCP> Chris Torek writes: > >> Storage Type Expression Equivalent >> ------------ --------------------- >> char int >> unsigned char unsigned int >> short int >> unsigned short unsigned int >> int int >> [more types] >It is interesting to note that K&R does not say that unsigned char or >unsigned short get promoted to unsigned int; it says that they get promoted >to integer (on page 183), which is a bit vague. Harbison & Steele says >very clearly what is said above. The ANSI Draft (1986.07.09 version) says >very clearly that unsigned char and unsigned short are promoted to int, >since the values can all be represented in an int (assuming sizeof(int) >is greater than sizeof(short), which is usually true). > >What to do? Frankly, I prefer the ANSI approach, but it does represent a >silent change from what H&S (and Chris Torek) perceive to be standard >practice. For some reason, it is not flagged as such in the rationale >document; it isn't even discussed there. I disagree. One cannot assume that sizeof(int) > sizeof(short). -- ------------- Brett Galloway {pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett
steiny@scc.UUCP (Don Steiny) (09/27/86)
In article <271@myrias.UUCP>, cmt@myrias.UUCP (Chris Thomson) writes: > It is interesting to note that K&R does not say that unsigned char or > unsigned short get promoted to unsigned int; it says that they get promoted > to integer (on page 183), which is a bit vague. Well, actually they do not mention unsigned char being as there was no such thing in Version VI or even many Version VII systems. In fact the system I am using right now, an Interdata 8/32 with Wollongong Edition VII does not have either unsigned char or unsigned long. What they say is that chars might sign extend and might not depending on the machine, which is even more confusing. -- scc!steiny Don Steiny @ Don Steiny Software 109 Torrey Pine Terrace Santa Cruz, Calif. 95060 (408) 425-0382
franka@mmintl.UUCP (Frank Adams) (10/06/86)
In article <271@myrias.UUCP> cmt@myrias.UUCP writes: >The ANSI Draft (1986.07.09 version) says >very clearly that unsigned char and unsigned short are promoted to int, >since the values can all be represented in an int (assuming sizeof(int) >is greater than sizeof(short), which is usually true). Usually isn't good enough. If this is what the ANSI Draft says, it should be fixed. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108