Re: configure output from largefile.m4

2024-06-18 Thread Bruno Haible
Paul Eggert wrote: > Thanks, I installed the attached which I hope is good enough. It's also > in Autoconf master now. Thanks!

Re: [PATCH 6/7] nstrftime, -0000

2024-06-18 Thread Bruno Haible
Paul Eggert wrote: > > After the Solaris crash fix, the nstrftime tests still fail, due to this > > output: > > > > <-00>0: expected "1970-01-01 00:00:00 - (-00)", got "1970-01-01 > > 00:00:00 + (-00)" > > <-00>0: expected "1985-11-05 00:53:21 - (-00)", got "1985-11-05 > > 00:53:21 +

Re: [PATCH 6/7] nstrftime, time_rz: don’t depend on tzname

2024-06-18 Thread Bruno Haible
Paul Eggert wrote: > > After the Solaris crash fix, the nstrftime tests still fail, due to this > > output: > > > > <-00>0: expected "1970-01-01 00:00:00 - (-00)", got "1970-01-01 > > 00:00:00 + (-00)" > > <-00>0: expected "1985-11-05 00:53:21 - (-00)", got "1985-11-05 > > 00:53:21 +

Re: [PATCH 6/7] nstrftime, -0000

2024-06-18 Thread Paul Eggert
On 2024-06-18 05:20, Bruno Haible wrote: Thanks. This is not documented in POSIX [1] nor in the man-pages [2]. Would it make sense that I suggest it to be documented in the man-pages? That'd be fine, yes. It's a convention in TZDB, e.g.: $ TZ=Factory date +'%Y-%m-%d %H:%M:%S %z (%Z)' 2024-

Re: [PATCH 6/7] nstrftime, time_rz: don’t depend on tzname

2024-06-18 Thread Paul Eggert
On 2024-06-18 06:02, Bruno Haible wrote: tz=NULL means universal time (a.k.a. GMT) in our strftime.h, but is undefined behaviour for NetBSD's functions. Thanks for the fix. I tweaked it via the attached. The "0" at the end of "UTC0" is better if the zoneinfo files are missing.From 562ed134d6cf

u*-vasnprintf: Fix handling of %ls, %lc directives on Solaris, MSVC

2024-06-18 Thread Bruno Haible
In lib/vasnprintf.c the first two invocations of DCHAR_MBSNLEN w = DCHAR_MBSNLEN (result + length, count); look wrong, because the memory beyond result + length has not been initialized at that point. This code handles the %ls and %lc directives. The platforms where this code is enabled are

mbslen: Add tests

2024-06-18 Thread Bruno Haible
The mbslen has 2 different implementations (one relying on mbuiterf, one relying on mcel). To avoid behavioural differences, a unit test is in order. 2024-06-18 Bruno Haible mbslen: Add tests. * tests/test-mbslen.c: New file. * tests/test-mbslen.sh: New file, based on

mbsnlen: Fix bug in mcel-based implementation

2024-06-18 Thread Bruno Haible
The new u*-vasnprintf tests that I added today succeed on all platforms. But on Solaris 11.4, in a testdir that contains also the 'mcel-prefer' module, they fail: FAIL: unistdio/test-ulc-vasnprintf3.sh == ../../gltests/unistdio/test-ulc-vasnprintf3.c:226: asse

copysignl tests: Avoid failure on Solaris 11.4

2024-06-18 Thread Bruno Haible
Building a testdir for module 'copysignl' on Solaris 11.4, with gcc in 64-bit mode without optimizations, I see a test failure: FAIL: test-copysignl ../../gltests/test-copysignl.c:90: assertion 'memcmp (&z, &zero, sizeof z) == 0' failed Stack trace: 0x408050 print_stack_tra

filemode: Add tests.

2024-06-18 Thread Collin Funk
I ran into a compilation error a long time ago (not Gnulib related) because I declared strmode using the mode_t argument unconditionally. This is an issue because FreeBSD uses int as the first argument and not mode_t, which is typedef'd to __uint16_t. This test is mostly to make sure that doesn't h