eggert at CS.UCLA.EDU
Wed Aug 4 20:24:17 UTC 2004
"Clive D.W. Feather" <clive at 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
#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
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.
More information about the tz