Re: parse-datetime test failure

[Paul Eggert]

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

0001-parse-datetime-tests-port-to-Alpine-Linux-3.12.1.patch
Description: Text Data

0002-parse-datetime-streamline-overflow-checking.patch
Description: Text Data

0003-time_rz-simplify-CVE-2017-7476-fix.patch
Description: Text Data