Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-16 10:59, Zack Weinberg wrote: I'm generally in agreement with Rich Felker's argument (inhttps://ewontfix.com/13/) that AC_CHECK_FUNC*should not* just probe for linkability of a symbol So am I. I'm not saying Autoconf should never change here, only that the change would not be

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-16 10:40, Jeffrey Walton wrote: This line of arguments is not persuasive. It is full of logical fallacies. ... none of which you stated. No matter how we solve the problem, it will be a hack that exploits "logical fallacies" (whatever that means). However, a reaction "You

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-16 06:26, Michael Matz wrote: char foobar(void); int main(void) { return != 0; } That still has undefined behavior according to draft C23, which says behavior is undefined when foobar is (say) 'memset_explicit' because the declaration 'char memset_explicit(void);' disagrees

Re: How can Autoconf help with the transition to stricter compilation defaults?

Can you cite any examples of a real-world security flaw what would be found by Clang erroring out because 'char foo(void);' is the wrong prototype? Is it plausible that any such security flaw exists? CVE-2006-1174 is a possibly reasonable example. CVE-2006-1174 is not an example, because no

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-15 11:27, Jonathan Wakely wrote: Another perspective is that autoconf shouldn't get in the way of making the C and C++ toolchain more secure by default. Can you cite any examples of a real-world security flaw what would be found by Clang erroring out because 'char foo(void);' is

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-15 06:50, Jonathan Wakely wrote: Could you clarify what you mean, with a concrete example? Surely as long as errors are reported on stderr and the compiler exits with non-zero status, that's an acceptable way to report errors? Not if the "error" is harmless as far as Autoconf is

Re: [PATCH] Basic support for checking NFSv4 ACLs in Linux

On 11/14/22 00:16, Ondrej Valousek wrote: The disadvantage is that it pulls back dependency on libacl for some reason (the code does not use libacl at all Yes, this needs to be fixed somehow, as part of the point of this Gnulib module is to not require programs like GNU ls to dynamically

[PATCH] parse-datetime: improve doc formatting, timeliness

insertions(+), 39 deletions(-) diff --git a/ChangeLog b/ChangeLog index d51a62a023..4ae5aefa54 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2022-11-14 Paul Eggert + + parse-datetime: improve doc formatting, timeliness + * doc/parse-datetime.texi: Use @samp and @code in menus

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-14 04:41, Aaron Ballman wrote: it's generally a problem when autoconf relies on invalid language constructs Autoconf *must* rely on invalid language constructs, if only to test whether the language constructs work. And Clang therefore must be careful about how it diagnoses invalid

Re: [PATCH] Basic support for checking NFSv4 ACLs in Linux

On 2022-11-11 00:40, Ondrej Valousek wrote: I think I have complete picture now. I also think that eventually I can eventually fix gnulib (hopefully the gnulib folks stay supportive) as there are already some pieces of code for AIX that I could possibly reuse. Thanks for taking this on.

make-stds.texi egrep/fgrep update in Gnulib

attached): https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=dda9eee96e18bdbfac023bdd1598e57a88f532ad Sorry about the confusion.From dda9eee96e18bdbfac023bdd1598e57a88f532ad Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 13 Nov 2022 10:44:49 -0800 Subject: [PATCH] autoupdate

Re: [PATCH] vc-list-files-tests: Avoid OpenPGP private key operations.

On 2022-11-13 02:59, Simon Josefsson via Gnulib discussion list wrote: I think this behaviour should generally be considered a bug. Yes. Tests shouldn't do that sort of thing, and we have to be cognizant of the privacy implications of code run by developers (as well as all the other

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-11 07:11, Aaron Ballman wrote: Clang doesn't require such a linker (we work with various system linkers). As long as the system linkers continue to work as they have traditionally worked, we're fine. the frontend perspective, we can't tell the difference between "trust me this

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-11 07:11, Aaron Ballman wrote: We believe the runtime behavior is sufficiently dangerous to warrant a conservative view that any call to a function will be a call that gets executed at runtime, hence a definitive signature mismatch is something we feel comfortable diagnosing (in some

Re: On time64 and Large File Support

On 2022-11-12 12:23, Wookey wrote: we can't just have everyone who enabled LFS sometime in the last 20 years suddenly being forced into the time_t change (can we?) We've done it in the past. AC_SYS_LARGEFILE originally was in Gnulib, before it migrated to Autoconf. Originally it affected

Re: On time64 and Large File Support

On 2022-11-12 10:50, Bruno Haible wrote: I'm saying "tiny" because we are still 15 years away, and new releases of the (not many) affected packages are likely to come in the next 1-2 years. Not so "tiny", I'm afraid. My department is still running a server with libraries and executables that

Re: On time64 and Large File Support

On 2022-11-11 18:20, Zack Weinberg wrote: I don’t think Paul considered the new behavior of AC_SYS_LARGEFILE to be overriding the glibc maintainers. Rather, I think he was only thinking about applications, not libraries, and only about source distribution. No, I was thinking about libraries

Re: On time64 and Large File Support

On 2022-11-12 06:16, Zack Weinberg wrote: I am going to go ahead and do this if nobody raises a concrete objection within the next 24 hours. I object to a simple reversion, as this will cause problems downstream with Gnulib-using applications, several of which have already been released

Re: On time64 and Large File Support

On 2022-11-11 03:38, Florian Weimer wrote: But that said, these binaries are broken anyway in 2038? No, I expect users to run them in time-shifted VMs or containers. That's reasonable for systems where accurate timestamps are not important and where time_t width mismatches would just get in

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-10 10:19, Aaron Ballman wrote: In terms of the Clang side of things, I don't think we've formed any sort of official stance on how to handle that yet. It's UB (you can declare the C standard library interface without UB but calling any function with a mismatched signature is UB) The

Re: How can Autoconf help with the transition to stricter compilation defaults?

On 2022-11-10 09:16, Zack Weinberg wrote: Changes to handle C23 built-in ‘bool’ better are under development but the design has not yet been finalized. [I'm cc'ing this to bug-gnulib too.] To my mind this is the biggest outstanding issue in Autoconf as far as C23 goes, as the upgrade path

Re: best way to deal with macOS deprecation of sprintf?

On 11/3/22 12:43, Jeffrey Walton wrote: Apple deprecated sprintf starting at MacOS 10.12. Yes, though that change in 10.12 apparently didn't adversely affect developers. What appears to be new in 10.13 is that the compiler is now warning about calls to sprintf. This is an unnecessary pain.

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

On 11/3/22 13:40, Karl Berry wrote: Whatever happens, can one of you make the desired changes in gnulib? Already done and installed, here: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=ddfcbc95a6be3ddc588a93f21edb69cc7c214d9c As part of that patch, I did the same sort of sync that

best way to deal with macOS deprecation of sprintf?

As noted in , macOS 13.0 has deprecated sprintf, on the grounds that buffer overflow happens too often with it. As a result, compilers will complain about any calls to sprintf, even if you don't configure with --enable-gcc-warnings. I assume vsprintf is similar.

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

On 2022-11-03 05:41, Bruno Haible wrote: Here are proposed patches to rename the modules. Thanks, those look good to me too.

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

On 2022-11-03 04:03, Florian Weimer wrote: I must say I was surprised to see dynarray and scratch_buffer end up in gnulib. I never intended them to escape this way from glibc. They escaped from glibc because they're used by code shared with Gnulib (e.g., canonicalize.c). The interfaces

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

On 11/2/22 19:37, Bruno Haible wrote: In other words, I'm suggesting to rename the modules scratch_buffer -> glibc-internal/scratch_buffer dynarray -> glibc-internal/dynarray I don't see any problem with that, since as far as I know the only current users of the two modules are

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

changed, 129 insertions(+), 194 deletions(-) delete mode 100644 lib/malloc/scratch_buffer_dupfree.c diff --git a/ChangeLog b/ChangeLog index 3dc7d8966f..0defe2469e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,30 @@ +2022-11-02 Paul Eggert + + scratch_buffer: adjust to glibc changes + Problem

Re: [PATCH] Basic support for checking NFSv4 ACLs in Linux

On 2022-10-31 01:05, Ondrej Valousek wrote: I do not quite understand why we are not calling acl_extended_file() any more on Linux This was due to a 2015 patch by Andreas Gruenbacher: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=da6ebc941e966141e83591408545224274d0cf0f that in

[PATCH 2/2] thread: pacify gcc -Wbad-function-cast

..634aa8797f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,9 @@ 2022-10-30 Paul Eggert + thread: pacify gcc -Wbad-function-cast + * lib/glthread/thread.h (gl_thread_self_pointer): With POSIX + threads, cast the call to gl_thread_t before casting to void *. + test

[PATCH 1/2] test-getlogin: pacify gcc -Wshadow

@@ -1,3 +1,8 @@ +2022-10-30 Paul Eggert + + test-getlogin: pacify gcc -Wshadow + * tests/test-getlogin.h (test_getlogin_result): Rename local. + 2022-10-25 Simon Josefsson gendocs: Output timestamp in English. diff --git a/tests/test-getlogin.h b/tests/test-getlogin.h index

Re: [PATCH] Basic support for checking NFSv4 ACLs in Linux

On 2022-10-28 07:33, Ondrej Valousek wrote: 2. The 'acl' package (as of today) only supports Posix ACLs and not the NFSv4 style. And besides, we do not use it anyway on modern Linux distros - see the code, instead of calling acl library, we just call getxattr() function directly. Is that the

Re: Avoid gnulib redefinitions - MDA, free-posix

On 2022-10-29 06:36, Gavin Smith wrote: Here is one idea. When using a module like 'free-posix', if it is loaded as a dependency only, use the redefinition in Gnulib code only, but do not override symbols in user code. It would be as if there were two modules, say gl-free-posix and free-posix,

Re: assert-h: Make static_assert work on Solaris 11.4

On 10/25/22 13:11, Bruno Haible wrote: The assert macro shall be implemented as a macro with an ellipsis parameter, not as an actual function. Thanks for clarifying it for me. I suppose the Gnulib assert-h module could be enhanced to support this C23 extension. Low priority for me as I

Re: assert-h: Make static_assert work on Solaris 11.4

On 2022-10-25 11:18, Jeffrey Walton wrote: Re: the ellipses. From https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2264r3.html, Section 8: Thanks. Although that sort of explains things, it doesn't explain why the latest draft uses ellipses only when NDEBUG is defined. Shouldn't

Re: assert-h: Make static_assert work on Solaris 11.4

On 2022-10-23 07:47, Bruno Haible wrote: #include #undef/**/assert + /* Solaris 11.4 defines static_assert as a macro with 2 arguments. +We need it also to be invocable with a single argument. */ + #if defined __sun && (__STDC_VERSION__ - 0 >= 201112L) && !defined __cplusplus +

Re: recent changes break gawk compilation

: Paul Eggert Date: Sat, 15 Oct 2022 13:30:07 -0700 Subject: [PATCH 1/2] Port to current Gnulib Adjust to current Gnulib, which uses C23 style keywords for bool, true, false and static_assert, and assumes that supplies compatibility macros on older systems. * awk.h: Do not include stdbool.h

Re: stdbool module unconditionally #define true

On 2022-10-14 14:08, Simon Josefsson via Gnulib discussion list wrote: Shouldn't the following cause a compilation error? $ podman run -it gcc:latest root@18544d251872:/# cat>foo.c int main (void) { int true = 42; return true; } Yes if you have a C23 compiler, which GCC 12 isn't. To get a

[PATCH] doc: improve intprops doc

-- 2 files changed, 77 insertions(+), 39 deletions(-) diff --git a/ChangeLog b/ChangeLog index 8abee26d10..16156b7cdd 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,14 @@ +2022-10-12 Paul Eggert + + doc: improve intprops doc + * doc/intprops.texi: Tighten up wording, by saying that

[PATCH 3/3] tests: prefer stdckdint to intprops

/ChangeLog @@ -1,5 +1,15 @@ 2022-10-10 Paul Eggert + tests: prefer stdckdint to intprops + * modules/chown-tests, modules/fchownat-tests: + * modules/fdutimensat-tests, modules/futimens-tests: + * modules/lchown-tests, modules/stat-time-tests: + * modules/utime-tests

[PATCH 2/3] stat-time: prefer stdckdint to intprops

, 8 insertions(+), 4 deletions(-) diff --git a/ChangeLog b/ChangeLog index c918d0e45e..0827f5c772 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,10 @@ 2022-10-10 Paul Eggert + stat-time: prefer stdckdint to intprops + * lib/stat-time.h: Include stdckdint.h instead of intprops.h

[PATCH 1/3] xalloc: remove stray includes + dependencies

2022-10-10 Paul Eggert + + xalloc: remove stray includes + dependencies + These used to be needed, but are not needed now. + * lib/xalloc.h: Do not include stdlib.h. + [GNULIB_XALLOC]: Do not include "intprops.h". + * lib/xmalloc.c: Include stdint.h here i

Re: bug#58163: coreutils instalation failure x86_64

Thanks for sending the extra data. Oh, I see you are running GCC 5.4. You have run into a GCC bug that I just now filed here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107116 This bug was in GCC 5 and is still present in GCC 12. To work around the GCC bug, please use './configure

[PATCH] assert-h: suppress Apple clang 13 false alarms

3b97909de5..74b496ddee 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2022-09-30 Paul Eggert + + assert-h: suppress Apple clang 13 false alarms + * m4/assert_h.m4 (gl_ASSERT_H): Suppress bogus warnings from Apple + clang 13 (clang-1300.0.29.30). Problem privately reported

Re: [PATCH] stdio-impl.h: Fix type of _offset field for Android

On 9/28/22 17:51, Tee KOBAYASHI wrote: On 32-bit Android fpos_t becomes a 64-bit type when large-file support is enabled, whereas _offset remains 32-bit. Out-of-bounds read/write could happen when _offset field is accessed in this situation. Thanks for the bug report, but does this actually

Re: gl_YEAR2038_EARLY is called too late

On 9/25/22 21:56, Daiki Ueno wrote: I guess a simple solution would be to swap the order of gl_YEAR2038_EARLY and AC_SYS_LARGEFILE in modules/largefile, as with the attached patch. Thanks, I installed that. This doesn't fully resolve the issue with DTLS tests as mentioned, and I suspect

Re: bug#58050: [INSTALLED] rm: fix diagnostics on I/O error

into Bug#58050. I fixed that by installing the attached into Gnulib.From e00de604fd7012fd912f7580cd658ed9363ed6ad Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 25 Sep 2022 18:33:49 -0700 Subject: [PATCH] fts: fix errno handling if dirfd fails MIME-Version: 1.0 Content-Type: text/plain; charset

Re: Don't #include gnulib-generated .h files from config.h

On 9/24/22 16:10, Bruno Haible wrote: Thus, it's best to avoid such a situation. This holds not only for but also for . For on the other hand I think the trouble is limited, because always exists among the system header files. These days stdbool.h falls into pretty much the same category

Re: lib/malloca.c: warning about [-Wsign-compare]

On 9/22/22 11:20, Bjarni Ingi Gislason wrote: CC='clang -Wsign-compare' ./gnulib-tool --test malloca 2> Oh, please don't use -Wsign-compare. Clang generates too many false alarms with -Wsign-compare, we don't recommend that warning, and Gnulib-using programs generally don't enable that

Re: lib/malloca.c: warning about [-Wsign-compare]

On 9/21/22 14:42, Bjarni Ingi Gislason wrote: you do not say for what you want (need) all this data. We need a reproducer to figure out what is causing the problem. Perhaps the problem involves something going wrong and generating the wrong config.h or Makefile. If so, what is it? If

[PATCH] assert-h: suppress clang false alarms

hanged, 17 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 29cea3c545..a6399f1048 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,16 @@ +2022-09-21 Paul Eggert + + assert-h: suppress clang false alarms + Suppress scads of annoying warnings from clang vers

Re: lib/malloca.c: error when compiling "groff"

On 9/18/22 09:36, Bjarni Ingi Gislason wrote: The source of the compilation error was the file "src/include/assert.h" in "groff". Removing it fixes the compilation. This makes it sound like the problem was a leftover assert.h from a previous build, which is not a Gnulib bug per se. If

Re: bool and C23

lways commented out) and a couple of minor opportunities for simplification, and installed the attached update.From 154986613fe8d25d086568426b394098a6f2f7aa Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 18 Sep 2022 11:26:36 -0700 Subject: [PATCH] =?UTF-8?q?stdbool:=20omit=20=E2=80=98#undef

Re: bool and C23

On 9/18/22 06:33, Bruno Haible wrote: #include "unitypes.h" +/* Get bool. */ +#include In examples like these would it make sense to do the following instead? This would avoid a bit of namespace pollution. #if !@HAVE_C_BOOL@ && !defined __cplusplus #include #endif

[PATCH] explicit_bzero-tests: robustify a bit

+ 2 files changed, 34 insertions(+), 20 deletions(-) diff --git a/ChangeLog b/ChangeLog index 8b3945834c..730460b591 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,20 @@ +2022-09-17 Paul Eggert + + explicit_bzero-tests: robustify a bit + This is mostly to suppress

Re: race condition in test-pthread_sigmask1?

On 9/17/22 16:00, Bruno Haible wrote: Any idea how we can make the test more reliable? Possibly the kernel is buggy and delivering the signal twice? If so, you can work around the bug by having the signal handler merely set the flag, rather than add 1 to it. If pid_t is wider than int,

Re: lib/malloca.c: error when compiling "groff"

Can you reproduce the problem with my recipe? One possibility is that you have an old malloca.c left over from an old build, and it won't compile with the new Gnulib. So it may help to bootstrap from scratch.

Re: lib/malloca.c: error when compiling "groff"

why malloca.c was being compiled. From 160932c99a650cc9c71a17acdc95cfc62f466ef1 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 14 Sep 2022 16:27:51 -0500 Subject: [PATCH] build: update gnulib submodule to latest --- gnulib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --g

[PATCH 2/2] assert-h: work around include confusion

/assert_h.m4 | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 1846e7c381..199b088200 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,12 @@ 2022-09-14 Paul Eggert + assert-h: work around include confusion + * m4/assert_h.m4 (gl_ASSERT_H

[PATCH 1/2] stdbool: depend on C99

/ChangeLog index 9c26d25bd0..1846e7c381 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2022-09-14 Paul Eggert + + stdbool: depend on C99 + Record that stdbool depends on C99 these days. + This matters only for ancient compilers that need special + flags to support

Re: [PROPOSED 2/2] assert-h: prefer to ‘verify’

# define static_assert _Static_assert /* C11 requires this #define. */ # endif Thanks for the fix. Should I also install the attached patch, for consistency? From e993a048cf8c58755da7c3b358cadf2f598bbff3 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 13 Sep 2022 23:01:53 -0500 Subject:

Re: [PROPOSED 0/2] static_assert and C23

rom c504bec035e90efceb212c538efc986ef3db7f7a Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 13 Sep 2022 17:29:35 -0500 Subject: [PATCH 1/4] assert-h: static_assert is a keyword in C23 * m4/assert_h.m4 (gl_ASSERT_H): Also test for static_assert keyword a la C23, and define HAVE_C_STATIC_ASSERT if so. If not, arrange for confi

Re: [PATCH] stdalign-tests: port to C23

On 9/13/22 15:19, Bruno Haible wrote: _Alignas is obsolescent? Although it's still in the standard as of draft C23, it is to some extent deprecated as it is no longer necessarily a keyword (it might be a macro). My guess is that it will be obsoleted in some future version of the standard,

[PATCH] stdalign-tests: port to C23

Paul Eggert + + stdalign-tests: port to C23 + * tests/test-stdalign.c: Do not test __alignas_is_defined, + _Alignof, or _Alignas as they are obsolescent. + Do not use __alignas_is_defined in C23 or later (or C++11 or later), + as it’s removed in C23. + 2022-09-12

[PROPOSED 2/2] assert-h: prefer to ‘verify’

+- tests/test-wchar.c | 4 +- 116 files changed, 368 insertions(+), 384 deletions(-) diff --git a/ChangeLog b/ChangeLog index 9e714143b9..8d20e0fae3 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,57 @@ 2022-09-12 Paul Eggert + assert-h: prefer to ‘verify

[PROPOSED 1/2] assert-h: static_assert is a keyword in C23

tests/test-assert.c diff --git a/ChangeLog b/ChangeLog index d812e73f55..9e714143b9 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,16 @@ +2022-09-12 Paul Eggert + + assert-h: static_assert is a keyword in C23 + * m4/assert_h.m4 (gl_ASSERT_H): Also test for static_assert + ke

[PROPOSED 0/2] static_assert and C23

static_assert even if you don't include . This patchset does differ from the bool patchset in that we can't assume the system supplies a static_assert macro since Gnulib doesn't assume C11. I haven't installed these into Gnulib. Comments welcome. Paul Eggert (2): assert-h: static_assert

[PATCH] maint: avoid unportable ERE \}

-11 Paul Eggert + maint: avoid unportable ERE \} + * top/maint.mk (sc_copyright_check): + Avoid unportable use of \} in ERE. + verify: improve maint check * top/maint.mk (sc_prohibit_verify_without_use): Adjust re to match verify.h. diff --git a/top

[PATCH] verify: improve maint check

@@ 2022-09-11 Paul Eggert + verify: improve maint check + * top/maint.mk (sc_prohibit_verify_without_use): + Adjust re to match verify.h. + verify: port better to C23 * lib/verify.h (_GL_VERIFY, static_assert): If C23, use static_assert keyword; no macro

[PATCH] verify: port better to C23

(-) diff --git a/ChangeLog b/ChangeLog index 38df593ab6..f4d9ce4139 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2022-09-11 Paul Eggert + + verify: port better to C23 + * lib/verify.h (_GL_VERIFY, static_assert): + If C23, use static_assert keyword; no macro

Re: bool and C23

Thanks for catching that doc bug. I installed into Gnulib the stdbool patches with a fix for that, and also with one small change to tests/test-stdbool.c so that it depends on HAVE_C_BOOL instead of __STDC_VERSION__. After we have more experience with this in Gnulib, we can start thinking

[PATCH] stdbool-tests: match stdbool

d7df9b16aa..99b476be6e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,10 @@ 2022-09-08 Paul Eggert + stdbool-tests: match stdbool + * tests/test-stdbool.c: Omit test for + __bool_true_false_are_defined since AC_CHECK_HEADER_STDBOOL no + longer checks

[PATCH] mktime: back in sync with GNUlib

-08 Paul Eggert + + mktime: back in sync with GNUlib + * config/srclist.txt: glibc has synced mktime from Gnulib. + 2022-09-07 Bruno Haible posix_spawn_file_actions_addclose tests: Avoid test failure on musl. diff --git a/config/srclist.txt b/config/srclist.txt index

Re: timespec_get: Fix compilation error with MSVC 14

On 9/4/22 17:00, Bruno Haible wrote: But I am lazy here, as 'timespec_get' is usually not the kind of function that people will call from an extern inline function. timespec_get is so new that I wouldn't expect it to be called from anywhere. Still, this business of "static inline" for

Re: stdbool: Fix compilation error in C++ mode with MSVC 14

On 9/4/22 09:25, Bruno Haible wrote: +# if !defined _MSC_VER +# define false false +# define true true +# endif How about using "#ifndef true" instead? That will be more portable in the presence of other platforms with this portability issue.

Re: timespec_get: Fix compilation error with MSVC 14

On 9/4/22 10:15, Bruno Haible wrote: this platform's contains a 'static inline' definition of timespec_get That violates the C standard, as it means an extern inline function cannot call timespec_get. Shouldn't we instead fix Gnulib's timespec_get module to work around this MSVC 14 bug?

Re: strtol, strtoul: Fix compilation error in C++ mode on Solaris 11

On 9/2/22 13:37, Bruno Haible wrote: +# if __GLIBC__ >= 2 _GL_CXXALIASWARN (strtol); +# endif Would it make sense to move the __GLIBC__ >= 2 check into _GL_CXXALIASWARN so that we needn't worry about making these sorts of patches? How much benefit to non-glibc ports do we obtain from

Re: ISO C 23 ahead

on platforms with working fnmatch, so the bad code was never compiled. From a5e751e79466703045e7d11d5d3dfc9e1d1fa78b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 30 Aug 2022 17:37:06 -0500 Subject: [PATCH] fnmatch: fix stdckdint typo * lib/fnmatch_loop.c (NEW_PATTERN): Fix typo in previous

Re: Creating a formula for Homebrew

On 8/25/22 18:20, dmitrii.pasech...@cs.ox.ac.uk wrote: There has been no official gnulib release in like 8 years... As far as I'm concerned none of the releases have been "official". Gnulib simply doesn't work that way. If you want something that does work that way, feel free to use Gnulib

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

00:00:00 2001 From: Paul Eggert Date: Thu, 25 Aug 2022 13:35:23 -0500 Subject: [PATCH] tempname: simplify by omitting _LIBC code * lib/tempname.c [_LIBC]: Simplify. Suggested by Bruno Haible in: https://lists.gnu.org/r/bug-gnulib/2022-08/msg00077.html I plan to propose a corresponding patch

Re: Creating a formula for Homebrew

On 8/25/22 09:53, dmitrii.pasech...@cs.ox.ac.uk wrote: I don't think this is how gnulib is usually used, and that's why regular releases are badly needed. It's how Gnulib developers (who do maintain other packages) usually use Gnulib. You're welcome to use releases if you like, though it's

[PATCH] * m4/gnulib-common.m4: Fix comment.

--- m4/gnulib-common.m4 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/m4/gnulib-common.m4 b/m4/gnulib-common.m4 index 30911d1581..8a5daa230e 100644 --- a/m4/gnulib-common.m4 +++ b/m4/gnulib-common.m4 @@ -313,7 +313,8 @@ AC_DEFUN([gl_COMMON_BODY], [ #else # define

Re: Bison submit patches

On 8/22/22 05:19, Andrei Malashkin wrote:please consider adding these patches to the next bison release https://github.com/conan-io/conan-center-index/pull/12439/commits/c3e05b98ba2c96c5b46b06d67eacac3d0d86a58e#diff-78354ca740cc9e125c777be4e3f9ec375c7d7d7c5368a3d4ab0c01357f42b58b

Re: bool and C23

On 8/22/22 15:58, Zack Weinberg wrote: There isn’t a bool module right now, are you proposing to add one? Yes. I want to get to where _no_ Gnulib module is required for bool; AC_C_BOOL by itself should be enough. Yes, that's the long term goal. But in the shorter term Gnulib-using code

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

8304617684ba7f71c36fcf49786d3b279dfbefc3 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 22 Aug 2022 12:22:52 -0700 Subject: [PATCH 1/3] tempname: merge 64-bit time_t fix from glibc This merges glibc commit 52a5fe70a2c77935afe807fb6e904e512ddd894e "Use 64 bit time_t stat internally". * lib/

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

On 8/17/22 04:08, Eli Zaretskii wrote: Would it be possible to cherry-pick this to the emacs-28 branch, so that Emacs 28.2 would have this fixed? I installed that.

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

On 8/16/22 12:59, Bruno Haible wrote: Since this contradicts what you debugged on mingw, I ran the test 1 times on native Windows. Result: - on 32-bit mingw, no failure. - on 64-bit mingw, around 30 failures (or around 10 failures with Paul's newest patch). That is, a probability

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

of this thread you rejected that patch, on the grounds that fixing the unlikely Emacs bug is more trouble than it's worth. So I'll drop that suggestion.From 512e44adaebb3096ddd1bf564e679d06e0301616 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 16 Aug 2022 12:06:48 -0700 Subject: [PATCH] tempname

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

On 8/16/22 10:04, Eli Zaretskii wrote: That "finite number" of 62^6 sounds pretty close to infinity to me! It's only 57 billion or so. That's not infinity, considering all the Emacs sessions out there. If Emacs's success grows, almost surely someone will run into this unlikely bug. Since we

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

On 8/16/22 09:25, Eli Zaretskii wrote: why does this work differently on different platforms? Platforms that lack clock_gettime and CLOCK_MONOTONIC fall back on a deterministic algorithm. Presumably MS-DOS one of the few such platforms, which is why the problem is observed only on MS-DOS.

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

On 8/16/22 09:25, Eli Zaretskii wrote: The programmer didn't expect that because it is natural to expect each call to a function that creates a temporary file to create a file under a new name, not reuse the same name. Regardless of whether the programmer expects a random name or a

Re: bool and C23

On 8/15/22 14:39, Bruno Haible wrote: to exclude other problems, we need to check it on a platform-by-platform basis. In the long run this problem will vanish, as in the long run config.h will do nothing (that's all that's needed for C23 and C++). In the shorter run I think we'll be OK for

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 15 Aug 2022 13:04:08 -0700 Subject: [PATCH] tempname: remove incorrect comment * lib/tempname.c, lib/tempname.h: Remove incorrect comment, as the names are not necessarily hard to predict (Bug#57129). --- ChangeLog | 6 ++ lib/tempname.c |

bool and C23

1f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 13 Aug 2022 20:00:02 -0700 Subject: [PATCH] stdbool: port to C23 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * m4/stdbool.m4 (AC_CHECK_HEADER_STDBOOL): Copy from bleeding-edge Autoconf. Don’t

Re: ISO C 23 ahead

On 8/10/22 06:58, Bruno Haible wrote: But you haven't pushed the patches yet. Oops. Pushed. And in patch 0004, I think the module 'stdckdint' should depend on 'stdbool' (since includes ). Thanks, I fixed that. I also sent the following email to people who I hope can fix the problems in

Re: ISO C 23 ahead

*/ # define assume(R) ((R) ? (void) 0 : /*NOTREACHED*/ (void) 0) #endif -- 2.34.1 From 7523bcf5dc9d8026006777c14e15c44430837f51 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 9 Aug 2022 23:20:49 -0700 Subject: [PATCH 2/6] intprops: refactor _GL_HAS_BUILTIN_OVERFLOW_P MIME-Version: 1.

[PATCH] largefile, year2038: simplify if Autoconf 2.72

+ m4/largefile.m4 | 7 ++- m4/year2038.m4 | 10 +- 3 files changed, 24 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 63691ebfb6..5dc57dc4f8 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2022-08-09 Paul Eggert + + largefile, year2038

Re: Report 3 bugs discoverd in gawk involving gnulib

On 8/3/22 02:38, YU Jiongchi wrote: Greetings, I have found 3 different stack overflow vulnerabilities in gawk. The developer mentioned that these bugs come from the gnulibs. The bugs report and POC files are attached in the attachment. Please feel free to contact me. Yes, this sort of

Re: split bootstrap in two phases

On 7/30/22 22:47, Bruno Haible wrote: Does the new documentation ([1], case 2, sub-case (C), as well as case 3) cover Emacs adequately? Yes, Emacs uses case (3), mostly I think because nobody but me wanted to worry about integrating with Gnulib.

Re: split bootstrap in two phases

On 7/30/22 16:43, Bruno Haible wrote: There is no actual collision, because your tool is 'autogen' [1], and this is 'autogen.sh'. For what it's worth Emacs has its own autogen.sh. But it doesn't use 'bootstrap' so I expect it won't collide.

<    3   4   5   6   7   8   9   10   11   12   >