[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200827140306.GR3265@brightrain.aerifal.cx>
Date: Thu, 27 Aug 2020 10:03:07 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: 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 <dalias@...c.org>)
> 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 <time.h> 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
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.
