[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200824161400.GG3265@brightrain.aerifal.cx>
Date: Mon, 24 Aug 2020 12:14:00 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: direct coding of asctime_r
On Sun, Aug 23, 2020 at 10:24:39AM +0200, Jens Gustedt wrote:
> Hello,
> I don't know if you guys noticed, but sometime ago we voted some of
> the ..._r functions from <time.h> into the C standard, just to then
> discover that POSIX has deprecated the whole set of functions and
> proposes to replace them by `strftime`.
>
> One of the arguments to keep them, was that `asctime_r` does not need
> access to locale and has a fixed format, and so can be implemented
> with a much smaller footprint.
>
> Looking into musl I found that the current implementation is basically
> doing verbatim what the C standard says, namely uses `snprintf` under
> the hood to do the formatting. This has obviously the disadvantage
> that this drags the whole infrastructure that is needed for `snprintf`
> into the executable.
>
> Making some tests, I found that coding `asctime_r` straight forward
> with byte-copying has it shave off about 10k from the final
> executable.
>
> Would it be interesting for musl to change to such an implementation?
>
> Shall I prepare a patch to do so?
I'm not *strongly* opposed to this, but my reasoning is fairly much in
line with the POSIX side, that these interfaces are legacy/deprecated,
and in general musl practice is to choose maximum simplicity over
size/performance optimality for deprecated/legacy or junk interfaces.
In particular, asctime[_r] formats dates in a legacy US format,
whereas modern applications should be using either ISO date format or
a locale-specific format.
Note that ISO C specifies asctime in terms of a particular printf
format string, meaning the results are well-defined for any values
that don't overflow the specified buffer, even if they are somewhat
nonsensical. In particular, as specified, it's required to accept
negative hours etc. if the year is such that it requires fewer than 4
digits. Direct coding this and ensuring all the cases are covered
seems nontrivial. One might argue that this is stupid and asctime is
not intended to be used in this way or useful to use in this way, and
I'd tend to agree but it's not something I'd want to argue with
someone who had a fairly legitimate claim that it's allowable
as-specified when there's no real compelling reason not to just
implement it as-specified with snprintf.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
