asctime.c

[Clive D.W. Feather]

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 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            |                            |