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 be
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
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.
> FAIL: test-parse-datetime
> =
>
> test-parse-datetime.c:434: assertion 'parse_datetime (&result, "TZ=\"\"",
> &now)' failed
> FAIL test-parse-datetime (exit status: 134)
The problem comes from the tzalloc function.
On NetBSD, tzalloc() is in libc, and tzalloc("\\")
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
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
Hi!
I reported a bug in gnutls 3.7.1
https://gitlab.com/gnutls/gnutls/-/issues/1190#note_528802421
and was told it might be a bug in gnulib instead.
The recipe from that bug report fails for me on NetBSD 9.99.81/amd64
with gcc 9.3.0:
git clone --depth=1 https://git.sv.gnu.org/git/gnulib.git
cd
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 be
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_se
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
Abo
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 (
11 matches
Mail list logo
