msb@sq.sq.com (Mark Brader) (08/30/89)
I'm transferring this discussion from comp.lang.c to comp.std.c. The following point of interpretation is one which had never occurred to me during the standardization process, and which I'd never seen discussed on the net until just now. The only thing that Section 3.1.2.5 of the proposed standard (pANS) guarantees about sizes of integral types is, in effect, that the sequence "sizeof(char), sizeof(short), sizeof(int), sizeof(long)" is nondecreasing, and that the presence of "signed" or "unsigned" doesn't affect the size. Section 2.2.4.2 in effect specifies minimum sizes for each type, but specifies nothing about maximum sizes. I believe there is nothing in the whole of Sections 2 or 3 of the pANS which requires any integral type to be *larger* than any other. But in a *hosted* implementation, Section 4 applies as well. And Doug Gwyn has just called attention in comp.lang.c to the fact that several library functions specified there, such as getchar(), are expected to convert an unsigned char value to type int. Considering an implementation where sizeof(int)==sizeof(char), Doug writes: > Since in such an implementation an int would be unable to represent > all possible values in the range of a unsigned char, as required by > the specification for some library routines, it would not be standard > conforming. Setting aside the fact that we're talking only about hosted environments here, this seems shaky to me. I can see two ways out of it, which makes three possibilities in all. [1] The wording of footnote 16 defining a so-called pure binary numeration system is so broad that it may allow an unsigned type to simply ignore the high-order bit position, provided that the corresponding signed type is at least one bit wider than the minimum otherwise required. Then int could be 16 bits, char could be 16 bits, and unsigned char could be 16 bits of which only the lower 15 are actually used. [2] The wording of the requirements of the aforementioned functions could be taken as specifying only that such a conversion be attempted, not that it be possible for all possible values of the argument. If int and char are both 16 bits, and getchar() reads the character 0xFEED from the input, then getchar() should be allowed to do whatever happens when you assign the positive value 0xFEED to an int variable, and anything else would be undefined behavior under the "invalid value" rule of 4.1.6. [3] The above argument is right and so sizeof(int)>sizeof(char) is required to be true, in a hosted environment only. I seem to recall that the Committee explicitly decided not to require that sizeof(int)>sizeof(char) when it was requested for other reasons, to do with avoiding surprises with unsigned types in comparisons. ("It was decided to allow implementers flexibility in this regard", or some such words.) Are they now finding that they did require this all along? -- Mark Brader "Many's the time when I've thanked the DAG of past years utzoo!sq!msb for anticipating future maintenance questions and providing msb@sq.com helpful information in the original sources." -- Doug A. Gwyn This article is in the public domain.