From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4478 invoked from network); 24 Aug 2020 16:14:19 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 24 Aug 2020 16:14:19 -0000 Received: (qmail 1795 invoked by uid 550); 24 Aug 2020 16:14:13 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1777 invoked from network); 24 Aug 2020 16:14:13 -0000 Date: Mon, 24 Aug 2020 12:14:00 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200824161400.GG3265@brightrain.aerifal.cx> References: <20200823102439.2bbaffb5@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200823102439.2bbaffb5@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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 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