Paul Eggert said:
Accepted, though your specific method isn't required. Yes, quite true. In all these cases the code could be rewritten if necessary. It's the cost of the rewrite that I object to.
Which is understandable.
[Incidentally, if I read it correctly you don't need to handle types larger than 16 bytes anyway.] Yes, POSIX requires support only for 1, 2, 4, 8, sizeof (short), sizeof (int), and sizeof (long).
But if sizeof (long) is 32, you don't have to support it because the entire line would be too long, right?
OK. Here's another example, obtained by the command "grep 'sizeof.*int'" in the coreutils source code. There are 59 grep matches, and the 4th match (I stopped looking after that) is broken on a host where we can't assume sizeof works as in C89. This macro takes any integer value x as an argument, and returns UINTMAX_MAX if x is all-one-bits in x's type; otherwise it returns x converted to uintmax_t.
#define PROPAGATE_ALL_ONES(x) \ ((sizeof (x) < sizeof (uintmax_t) \ && (~ (x) == (sizeof (x) < sizeof (int) \ ? - (1 << (sizeof (x) * CHAR_BIT)) \ : 0))) \ ? UINTMAX_MAX : (x))
Admittedly this is a less-clean example, since it also assumes a two's complement host in which integers narrower than "int" do not have "holes" in their representation.
There definitely *are* architectures for which that isn't the case - when working on C99, we knew that there are systems where the unsigned types simply ignore the sign bit rather than using it as a most significant bit. There's even one system where integers are stored as floating-point values with the exponent ignored. With that assumption, both C89 and C99 have the "sizeof ordering" you desire. Without it, I think that code is broken anyway. (I also don't see why you're special-casing uintmax_t at the start.) It will also break on a perverse C89 system where USHRT_MAX > UINT_MAX (C99 forbids this).
However, we still have the case that, within the constraints allowed by this coding standard, the relaxation of the C89 sizeof rules "breaks" this code.
I don't think so, because if there are no holes then the requirements on range imply the requirements on sizeof.
Now that I'm thinking of this, I should probably just change the coding standard to say that it's OK to assume sizeof(int)<=sizeof(long). That will solve the problem for us, anyway. It wouldn't be the first time that the GNU coding standards have said it's OK to assume properties guaranteed by C89 but not C99.
I hope you say this "only for code being maintained, not for new code". That way it will eventually die out. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |