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
