From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13455 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: [PATCH libc-test] add strptime basic test Date: Fri, 16 Nov 2018 16:34:53 -0500 Message-ID: <20181116213453.GK5150@brightrain.aerifal.cx> References: <20181115073456.11105-1-zajec5@gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1542403988 32023 195.159.176.226 (16 Nov 2018 21:33:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Nov 2018 21:33:08 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: musl@lists.openwall.com, rafal@milecki.pl To: Bartosz Brachaczek Original-X-From: musl-return-13471-gllmg-musl=m.gmane.org@lists.openwall.com Fri Nov 16 22:33:03 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1gNljZ-00088g-7a for gllmg-musl@m.gmane.org; Fri, 16 Nov 2018 22:33:01 +0100 Original-Received: (qmail 8184 invoked by uid 550); 16 Nov 2018 21:35:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7979 invoked from network); 16 Nov 2018 21:35:08 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13455 Archived-At: On Fri, Nov 16, 2018 at 10:21:01PM +0100, Bartosz Brachaczek wrote: > On Thu, Nov 15, 2018 at 11:12 AM Rafał Miłecki wrote: > > > On 15.11.2018 08:34, Rafał Miłecki wrote: > > > From: Rafał Miłecki > > > > > > Signed-off-by: Rafał Miłecki > > > > 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? Yes, I think this calls for a defect report/request for interpretation. Even if one intends that tm_[wy]day be updated, there is no canonical correct way to do it. Certainly it can't happen without sufficiently many constraints to determine the value, and it's not clear what would happen when %a, %w, etc. are also present. Overall, strptime is severely under-specified, and musl tends to err on the side of not doing anything it's not specified to do, since it could turn out that such action is contrary to intended interpretation or future changes to the standard, in which case applications depending on the behavior could be broken by fixing musl to conform. Rich