From: Rich Felker <dalias@libc.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: "Bruno Haible" <bruno@clisp.org>,
bug-gnulib@gnu.org, "Simon Josefsson" <simon@josefsson.org>,
"Pádraig Brady" <P@draigBrady.com>,
musl@lists.openwall.com
Subject: Re: [musl] Re: parse-datetime test failure
Date: Wed, 11 Nov 2020 23:07:57 -0500 [thread overview]
Message-ID: <20201112040755.GR534@brightrain.aerifal.cx> (raw)
In-Reply-To: <e08b126d-fb6a-8b6b-676c-c5815da86f80@cs.ucla.edu>
On Wed, Nov 11, 2020 at 07:38:00PM -0800, Paul Eggert wrote:
> On 11/11/20 8:20 AM, Bruno Haible wrote:
> >It works fine on Alpine Linux 3.7 (32-bit, 64-bit) and 3.9 (64-bit).
> >
> >On Alpine Linux 3.10 and 3.12 (64-bit) it fails:
> >../../gltests/test-parse-datetime.c:448: assertion 'result.tv_sec == 1 * 60 * 60 + 2 * 60 + 3 && result.tv_nsec == 123456789' failed
> >Aborted
> >
> >So, to me it looks like a regression between Alpine Linux 3.9 and 3.10.
>
> It's arguably a bug in the test case, since Alpine uses musl libc
> which does not support time zone abbreviations longer than 6 bytes,
> whereas the test case uses an time zone abbreviation of 2000 bytes
> (to test a bug in an old Gnulib version when running on GNU/Linux).
> POSIX does not define behavior if you go over the limit.
>
> I worked around the problem by changing the test case to not go over
> the limit as determined by sysconf (_SC_TZNAME_MAX), in the first
> attached patch. Plus I refactored and/or slightly improved the
> Gnulib overflow checking while I was in the neighborhood (last two
> attached patches).
>
> Arguably this is a quality-of-implementation issue here, since
> Alpine and/or musl goes beserk with long timezone abbreviations
> whereas every other implementation I know of either works or
> silently substitutes localtime or UTC (which is good enough for this
> test case). But I'll leave that issue to the Alpine and/or musl libc
> folks.
>
> I'll cc this to the musl bug reporting list. Although the Gnulib
> test failure has been fixed, it may be the symptom of a more-severe
> bug in musl. For those new to the problem, this thread starts here:
>
> https://lists.gnu.org/r/bug-gnulib/2020-11/msg00039.html
Thanks. I believe you've just re-discovered a known bug that's fixed
in musl commit 33338ebc853d37c80f0f236cc7a92cb0acc6aace, which will be
included in the upcoming 1.2.2 release.
Rich
next prev parent reply other threads:[~2020-11-12 4:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87o8k4urq2.fsf@latte.josefsson.org>
[not found] ` <4957782.yBLirf3sRb@omega>
2020-11-12 3:38 ` Paul Eggert
2020-11-12 4:07 ` Rich Felker [this message]
2020-11-12 4:10 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201112040755.GR534@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=P@draigBrady.com \
--cc=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=musl@lists.openwall.com \
--cc=simon@josefsson.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).