[PATCH 4/4] posix_memalign: port better to OpenBSD 6.2+ cross

* m4/posix_memalign.m4 (gl_FUNC_POSIX_MEMALIGN): Don’t assume sizeof (void *) <= 32 (!). The bug is fixed in OpenBSD 6.2+. --- ChangeLog| 5 + m4/posix_memalign.m4 | 18 +++--- 2 files changed, 16 insertions(+), 7 deletions(-) diff --git a/ChangeLog b/ChangeLog index

[PATCH 3/4] posix_memalign-tests: fix message typo

* tests/test-posix_memalign.c (main): Fix diagnostic typo. --- ChangeLog | 3 +++ tests/test-posix_memalign.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 9360b71007..6b65268fa2 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1

[PATCH 2/4] aligned_alloc: document glibc bug 32301

* doc/posix-functions/aligned_alloc.texi: * doc/posix-functions/posix_memalign.texi: Mention glibc bug 32301, which it is not worth our time to work around. --- ChangeLog | 5 + doc/posix-functions/aligned_alloc.texi | 5 + doc/posix-functions/posix_memalign.

[PATCH 1/4] eealloc: update commentary

Even if we remove eealloc we might as well add commentary explaining some of its confusion, before we remove it. * lib/eealloc.h: Update comment. * modules/eealloc (Description): Update, since eealloc is not glibc compatible. --- ChangeLog | 9 + lib/eealloc.h | 28 +++

Re: [PATCH] crc: New optimised slice-by-8 implementation

[Please keep the mailing list in CC.] Sam Russell wrote: > > 1) Add into comments references to the research papers that are used in > >or are useful to understand the code. Like the "Intel paper" that you > >showed us in the beginning. > > done > > > 2) Generate the tables at build time

Re: [PATCH] crc: New optimised slice-by-8 implementation

Hi Sam, > Sorry for the multiple bumps, but this patch offers a 77% reduction in > compute time for CRC an a 35% reduction in gzip time, Thanks for following through! > if this patch is not compliant then can some please let me know I would suggest three things: 1) Add into comments references

Re: [PATCH] crc: New optimised slice-by-8 implementation

Hi team, Sorry for the multiple bumps, but this patch offers a 77% reduction in compute time for CRC an a 35% reduction in gzip time, if this patch is not compliant then can some please let me know and I am happy to do whatever it take to make it compliant so we can all benefit from the speedups.

regex: Avoid dialog while running configure test on Haiku/x86_64

On Haiku, the regex test runs into a libc-internal assertion (both from regexec.c:1377:pop_fail_stack: num >= 0 and from glibc bug 11053. This is annoying, because it requires human intervention for the build to continue. Fixed like this: 2024-10-26 Bruno Haible regex: Avoid dialog

regex: Make configure test more maintainable

Since M_CHECK_ACTION is only defined in , it is confusing that the test program tests it _before_ having included . (Fortunately this does not produce a bug, since HAVE_DECL_ALARM is 1 on glibc.) But anyway, it's better written like this: 2024-10-26 Bruno Haible regex: Make configure

Re: execute, spawn-pipe: Support DLL dependencies of Windows executables

I did: > * lib/windows-path.h: New file. > * lib/windows-path.c: New file. Oops. On Cygwin 3.x, the CI reports a compilation error: In file included from ../../lib/windows-path.c:18: ./config.h:3273:29: error: 'free' undeclared here (not in a function) 3273 | _GL_ATTRIBUTE_DEALL

Re: pipe_filter_gi_create implementation do not match what is documented.

Hi, Miro Palmu wrote: > In lib/pipe-filter.h above pipe_filter_gi_create is says: > > > If the subprocess does not start correctly, > > exit if exit_on_error is true, otherwise return NULL and set errno. > > However looking at the implementation (lib/pipe-filter-gi.c) > of the case that exit_on_

pipe_filter_gi_create implementation do not match what is documented.

In lib/pipe-filter.h above pipe_filter_gi_create is says: If the subprocess does not start correctly, exit if exit_on_error is true, otherwise return NULL and set errno. However looking at the implementation (lib/pipe-filter-gi.c) of the case that exit_on_error is false, it seems that what is

Re: Improve getopt error strings?

Thanks for the suggestion. That part of Gnulib is maintained by glibc, so bug reports should be sent there. POSIX mildly suggests the wordings of the first two strings you mention, here: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/getopts.html#tag_20_53_18 Although the wording

Improve getopt error strings?

Hello everybody, during the revision phase of the Italian .po files for gettext, another Italian translator (Daniele Forsi) suggested improvements for the getopt error strings [1]. 1. We have: "%s: invalid option -- '%c'\n" "%s: option requires an argument -- '%c'\n" Whereas other error messages

Re: [Manual CSS] Suggested changes

Hello Paul, Le 26/10/2024 à 00:11, Paul Eggert a écrit : Thanks for the suggestions. I installed the attached patch to , as I think that's what you had in mind. If I'm wrong please let us know. Thanks a lot for applying this patch. It's just fin