Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGxPR-88phE1yeA3nhje15kbgt9csVShCMvqdS7p7DmJtEoMmg@mail.gmail.com>
Date: Fri, 16 Nov 2018 22:21:01 +0100
From: Bartosz Brachaczek <b.brachaczek@...il.com>
To: musl@...ts.openwall.com
Cc: rafal@...ecki.pl
Subject: Re: Re: [PATCH libc-test] add strptime basic test

On Thu, Nov 15, 2018 at 11:12 AM Rafał Miłecki <zajec5@...il.com> wrote:

> On 15.11.2018 08:34, Rafał Miłecki wrote:
> > From: Rafał Miłecki <rafal@...ecki.pl>
> >
> > Signed-off-by: Rafał Miłecki <rafal@...ecki.pl>
>
> I've just tried it with musl (I should have done that before sending a
> patch) and noticed is fails with:
>
> "%Y-%m-%d": for "1991-08-25" expected 1991-08-25T00:00:00 (day 237: Sun)
> but got 1991-08-25T00:00:00 (day 001: Sun)
> "%d.%m.%y": for "25.08.91" expected 1991-08-25T00:00:00 (day 237: Sun) but
> got 1991-08-25T00:00:00 (day 001: Sun)
> "%D": for "08/25/91" expected 1991-08-25T00:00:00 (day 237: Sun) but got
> 1991-08-25T00:00:00 (day 001: Sun)
> "%d.%m.%y": for "21.10.15" expected 2015-10-21T00:00:00 (day 294: Wed) but
> got 2015-10-21T00:00:00 (day 001: Sun)
> "%d.%m.%y in %C th": for "10.7.56 in 18th" expected 1856-07-10T00:00:00
> (day 192: Thu) but got 1856-07-10T00:00:00 (day 001: Sun)
>
> which I didn't expect.
>
> It's because I assumed glibc behavior which sets tm_wday and tm_yday.
>
> The man says:
> "In principle, this function does not initialize tm but stores only the
> values specified."
>
> There is a glibc behavior however:
> "Details differ a bit between different UNIX sys-tems.  The glibc
> implementation does not touch those fields which are not explicitly
> specified, except that it recomputes the tm_wday and tm_yday field if
> any of the year, month,  or  day  elements changed."
>
> I guess a correct test should allow any behavior and don't test tm_wday
> and tm_yday fields.
>
>
> It also fails with:
>
> "%F": failed to parse "1856-07-10"
> "%s": failed to parse "683078400"
> "%z": failed to parse "+0200"
> "%z": failed to parse "-0530"
> "%z": failed to parse "-06"
>
> but that's expected due to unimplemented %F %s and %z.
>

I cannot find anything in the normative text that would suggest that
recomputing tm_wday and/or tm_yday is required, but interestingly enough,
the strptime example that is used in POSIX seems to rely on that. See:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/strptime.html.
That example does not produce expected output using musl.

Possibly something that should be clarified in POSIX?

Content of type "text/html" skipped

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.