Clive D.W. Feather
clive at demon.net
Thu Aug 5 06:28:17 UTC 2004
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
> #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 at demon.net> | Tel: +44 20 8495 6138
Internet Expert | Home: <clive at davros.org> | Fax: +44 870 051 9937
Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc | |
More information about the tz