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 31561 invoked from network); 27 Aug 2020 14:03:23 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 27 Aug 2020 14:03:23 -0000 Received: (qmail 7477 invoked by uid 550); 27 Aug 2020 14:03:20 -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 7453 invoked from network); 27 Aug 2020 14:03:19 -0000 Date: Thu, 27 Aug 2020 10:03:07 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200827140306.GR3265@brightrain.aerifal.cx> References: <20200823102439.2bbaffb5@inria.fr> <20200824161400.GG3265@brightrain.aerifal.cx> <20200827112759.7e04abd3@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200827112759.7e04abd3@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] direct coding of asctime_r On Thu, Aug 27, 2020 at 11:27:59AM +0200, Jens Gustedt wrote: > Rich, > > on Mon, 24 Aug 2020 12:14:00 -0400 you (Rich Felker ) > wrote: > > > 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. > > But which is also a format used by the language itself (or refered to) > by `__TIME__` and similar macros. Yes, that doesn't indicate that it should continue to be used, though. And in theory you can use __TIME__ just to parse and convert to a more reasonable form. > > 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. > > I don't think so. The general rules for valid arguments to C library > functions always apply, so according to 7.1.4 calls to the functions > with values that are outside the specified ranges for the type have > UB. The range of the type is [INT_MIN,INT_MAX]. For tm_wday and wm_mon, UB of out-of-normal-range values would be established just by omission of any spec for what they do. However you missed the actual text in support of your claim, 7.27.3.1 ¶3: "If any of the members of the broken-down time contain values that are outside their normal ranges,323) the behavior of the asctime function is undefined." Normal ranges are defined in 7.27.1 ¶4. So this removes my main potential objection and the remaining question is just whether this is a size optimization that makes sense. > In the header the only exception from this rule seems to be > `mktime`, which makes such exceptions explicit and says how the > argument is normalized if it is not in the ranges as specified. > > The sample code that I posted does range checks with simple means that > never results in unbounded UB and always returns a string that is null > terminated. I would think that this is reasonable behavior. I think the behavior of crashing on inputs that are UB and that can't safely be printed should probably be preserved, too; I'm not clear if you had that in mind already. I'm rather indifferent on what happens for inputs that are UB but that can faithfully be presented in the allotted space. Rich