Re: tzalloc (was: Re: parse-datetime test failure on NetBSD)

2021-03-14 Thread Paul Eggert
On 3/14/21 11:33 AM, Bruno Haible wrote: A close term is "multithread-safe". The API could be implemented in a multithread-safe way, but time_rz.c is not multithread-safe, due to the function 'change_env'. It is planned to provide a multithread-safe implementation at some point? My plan has

Re: tzalloc (was: Re: parse-datetime test failure on NetBSD)

2021-03-14 Thread Bruno Haible
Paul Eggert wrote: > > On NetBSD, tzalloc() is in libc, and tzalloc("\\") returns NULL. > > On other platforms, tzalloc() comes from Gnulib, and tzalloc("\\") returns > > non-NULL. > > > > Which behaviour is correct? > > Both. The set of supported TZ values is system-dependent. OK, then we need

Re: tzalloc (was: Re: parse-datetime test failure on NetBSD)

2021-03-14 Thread Paul Eggert
On 3/14/21 4:53 AM, Bruno Haible wrote: On NetBSD, tzalloc() is in libc, and tzalloc("\\") returns NULL. On other platforms, tzalloc() comes from Gnulib, and tzalloc("\\") returns non-NULL. Which behaviour is correct? Both. The set of supported TZ values is system-dependent.

tzalloc (was: Re: parse-datetime test failure on NetBSD)

2021-03-14 Thread Bruno Haible
> FAIL: test-parse-datetime > = > > test-parse-datetime.c:434: assertion 'parse_datetime (, "TZ=\"\"", > )' failed > FAIL test-parse-datetime (exit status: 134) The problem comes from the tzalloc function. On NetBSD, tzalloc() is in libc, and tzalloc("\\") returns

Re: parse-datetime test failure on NetBSD

2021-03-14 Thread Thomas Klausner
On Sun, Mar 14, 2021 at 11:42:43AM +0100, Bruno Haible wrote: > Hi Thomas, > > > The recipe from that bug report fails for me on NetBSD 9.99.81/amd64 > > with gcc 9.3.0: > > With version of Bison are you using? 3.7.5 Thomas

Re: parse-datetime test failure on NetBSD

2021-03-14 Thread Bruno Haible
Hi Thomas, > The recipe from that bug report fails for me on NetBSD 9.99.81/amd64 > with gcc 9.3.0: With version of Bison are you using? Bruno

Re: [musl] Re: parse-datetime test failure

2020-11-11 Thread Paul Eggert
On 11/11/20 8:07 PM, Rich Felker wrote: Thanks. I believe you've just re-discovered a known bug that's fixed in musl commit 8ebc853d37c80f0f236cc7a92cb0acc6aace, which will be included in the upcoming 1.2.2 release. Yes, thanks, that looks exactly right. It's *so* nice to have bugs fixed

Re: [musl] Re: parse-datetime test failure

2020-11-11 Thread Rich Felker
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

Re: parse-datetime test failure

2020-11-11 Thread 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

Re: parse-datetime test failure

2020-11-11 Thread Bruno Haible
Hi Simon, > I noticed the test-parse-datetime fails on Alpine Linux, and > probably has failed since 2017-04-26 when the "Outlandishly-long time > zone abbreviations" test was added. (It could also be a recent > regression, of course.) It works fine on Alpine Linux 3.7 (32-bit, 64-bit) and 3.9