"Clive D.W. Feather" <clive@demon.net> writes:
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.
[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).
I am having difficulty figuring out why someone would do that at all. You've given me one example.
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. (The brief coding standard for this code allows this assumptions; see "Portability guidelines" under <http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/gnulib/gnulib/README?rev=...>.) 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. 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.