Re: [PATCH 3/4] largefile: sync from Autoconf master

Another doc tweak: The wording "fixed by the Gnulib modules year2038-required and year2038" is ambiguous: It can be interpreted that the user needs both of these modules in order to get the fixes. We have this situation e.g. with the 'stdio' and the 'sigpipe' module. There, to emphasize the "and",

doc: Clarify list of platforms for year2038 support

To test the new largefile + year2038 changes, I created a gnulib testdir ./gnulib-tool --create-testdir --dir=../testdir --single-configure largefile-required year2038-required and compiled it on various platforms. Here are the results, by ABI: i386 Linux: Ubuntu 22.04 OK

recommending AC_SYS_YEAR2038_REQUIRED ?

Hi Paul, In yesterday's changes, you added to the Gnulib documentation, section "Avoiding the year 2038 problem", wording that * explicitly recommends the ‘year2038-required’ module, which does AC_REQUIRE([AC_SYS_YEAR2038_REQUIRED]): "The Gnulib module ‘year2038-required’ is recommende

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

On 10/04/2023 14:40, Bruno Haible wrote: Hi Paul, In yesterday's changes, you added to the Gnulib documentation, section "Avoiding the year 2038 problem", wording that * explicitly recommends the ‘year2038-required’ module, which does AC_REQUIRE([AC_SYS_YEAR2038_REQUIRED]): "The G

Re: stddef: Define 'unreachable', for ISO C 23 compliance

On 16/03/2023 12:48, Bruno Haible wrote: ISO C 23 § 7.21.1 requires that implements 'unreachable'. This patch does it. 2023-03-16 Bruno Haible stddef: Define 'unreachable', for ISO C 23 compliance. * lib/verify.h (_GL_HAS_BUILTIN_UNREACHABLE): Don't define if already

Re: stddef: Define 'unreachable', for ISO C 23 compliance

Hi Pádraig, > > +/* Declare abort(), without including . */ > > +extern > > +# if defined __cplusplus > > +"C" > > +# endif > > +_Noreturn > > The above _Noreturn is causing a build failure on Solaris 10 on Sparc. A build failure of which package, which version? Can you please show the tail

Re: stddef: Define 'unreachable', for ISO C 23 compliance

On 10/04/2023 18:46, Bruno Haible wrote: Hi Pádraig, +/* Declare abort(), without including . */ +extern +# if defined __cplusplus +"C" +# endif +_Noreturn The above _Noreturn is causing a build failure on Solaris 10 on Sparc. A build failure of which package, which version? Can you ple

Re: stddef: Define 'unreachable', for ISO C 23 compliance

On 10/04/2023 19:05, Pádraig Brady wrote: On 10/04/2023 18:46, Bruno Haible wrote: Hi Pádraig, +/* Declare abort(), without including . */ +extern +# if defined __cplusplus +"C" +# endif +_Noreturn The above _Noreturn is causing a build failure on Solaris 10 on Sparc. A build failure of

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

On Mon, Apr 10, 2023, at 10:12 AM, Pádraig Brady wrote: > On 10/04/2023 14:40, Bruno Haible wrote: >> Hi Paul, In yesterday's changes, you added to the Gnulib >> documentation, section "Avoiding the year 2038 problem", wording that >> >>* explicitly recommends the ‘year2038-required’ module, wh

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

Zack Weinberg wrote: > As the person who invented AC_SYS_YEAR2038_REQUIRED and > AC_SYS_LARGEFILE_REQUIRED, let me say that it was my intention that they > would only be used in rare circumstances, where the inability to install > the software on older ABIs is outweighed by some other strong > requ

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

On 2023-04-10 12:09, Zack Weinberg wrote: I was imagining something to do with library ABIs involving time_t, or network and/or storage formats explicitly specified to use 64-bit counts of seconds since the Unix epoch, or similar. Needs are not limited to library code. Applications like 'ls' an

behavioral change in coreutils `pwd` handling '//' (double slash) caused by gnulib update

I am investigating a possible regression in gnulib that manifests as a behavioral change in coreutils `pwd` on some Linux platforms. Comparing coreutils 9.1 and 9.2 release tarballs, freshly built: $ x=$(pwd) && (cd //tmp && for k in 9.1 9.2; do echo -n $k:\ && ${x}/coreutils-$k/src/pwd; done)

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

Hi Paul, I want to avoid year-2038 breakage as much as you want. But what you are doing in coreutils and recommending through the Gnulib manual goes beyond that goal. > Applications like 'ls' and 'date' > and even 'grep' need support for timestamps past 2038. ... if they are used in hardware th

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

Paul, Here's a suggestion for a compromise. Recall that the macro AC_SYS_YEAR2038_REQUIRED is like AC_SYS_YEAR2038, with two modifications: - It causes configure to fail if a large 'time_t' is unavailable, - It removes the configure option --disable-year2038. How about a middle ground betwee

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

On 2023-04-10 14:42, Bruno Haible wrote: How about a middle ground between the two macros? A macro, say AC_SYS_YEAR2038_UNLESS_OPT_OUT (*), that - like AC_SYS_YEAR2038, has the option --disable-year2038, - like AC_SYS_YEAR2038_REQUIRED, fails if a large 'time_t' is unavailable and --di

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

On 2023-04-10 14:08, Bruno Haible wrote: Applications like 'ls' and 'date' and even 'grep' need support for timestamps past 2038. ... if they are used in hardware that will operate in and beyond 2038. That's not the only reason year-2038 support is needed. And it's not just trivial things lik

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

Paul Eggert wrote: > > How about a middle ground between the two macros? A macro, say > > AC_SYS_YEAR2038_UNLESS_OPT_OUT (*), that > >- like AC_SYS_YEAR2038, has the option --disable-year2038, > >- like AC_SYS_YEAR2038_REQUIRED, fails if a large 'time_t' is > > unavailable and --disabl

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

On 2023-04-10 15:36, Bruno Haible wrote: I like this. Thanks. OK, then let's hear Zack's opinion and hopefully move forward. In the meantime I installed the attached Gnulib patch, which documents the current situation better as you suggested (e.g., by suggesting year2038 first) and updates s

Re: behavioral change in coreutils `pwd` handling '//' (double slash) caused by gnulib update

On 2023-04-10 12:00, Zach van Rijn wrote: The gnulib commit that caused this behavioral change is: 356a414e8c15ef3f8cc7b7157427c8ce9a9f7c1b I'm not seeing any behavior change on Ubuntu, because building coreutils on Ubuntu doesn't need to compile lib/getcwd.c. That is, in your situation

alignasof: Ensure a correct _Alignas

Building a testdir on AIX 7.2 with xlc, I get this compilation error: xlc -qthreaded -qtls -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -I. -I../../gltests -I.. -DGNULIB_STRICT_CHECKING=1 -DIN_GNULIB_TESTS=1 -I. -I../../gltests -I.. -I../../gltests/.. -I../gllib -I../../gltests/../gllib -I/home

Re: alignasof: Ensure a correct _Alignas

Thanks for fixing that. On 2023-04-10 18:06, Bruno Haible wrote: - ISO C 11 specifies that defines alignas, alignof, __alignas_is_defined, __alignof_is_defined, and nothing else. - GCC's and clang's private do the same: They don't define _Alignas either. That's to be expected

Re: doc: Clarify list of platforms for year2038 support

Oh, I forgot to send comments that partly explain my recent changes in this area. Here they are, belatedly: On 2023-04-10 05:56, Bruno Haible wrote: +@item +Linux/riscv32, says this platform used 64-bit time_t "from the get go". +Linux with musl libc on