Re: Does anybody use Gnulib's eealloc module?

Hi Paul, Paul Eggert writes: > Does any package use Gnulib's eealloc module? Although it seems to > code stolen from Coreutils in 2006, as far as I can see Coreutils has > never used the module, though Coreutils does use m4/eealloc.m4 which > comes with Gnulib's malloca, regex, and relocatable-p

Does anybody use Gnulib's eealloc module?

Does any package use Gnulib's eealloc module? Although it seems to code stolen from Coreutils in 2006, as far as I can see Coreutils has never used the module, though Coreutils does use m4/eealloc.m4 which comes with Gnulib's malloca, regex, and relocatable-prog-wrapper modules. I'm asking bec

[PATCH 1/7] realloc: still more improvements for realloc (p, 0)

* doc/posix-functions/malloc.texi: AIX is sans _LINUX_SOURCE_COMPAT. * doc/posix-functions/realloc.texi: Give more details about what recent POSIX versions say, and fix some misperceptions about C89 through C11. Document that the GNU behavior does not conform to POSIX, and that AIX's behavior with

[PATCH 7/7] realloc: minor style coalescing

* lib/alignalloc.h (alignalloc): * lib/eealloc.h (eerealloc): * lib/ialloc.h (irealloc, ireallocarray): * lib/safe-alloc.h (safe_alloc_realloc_n): Adjust commentary and code to better match what’s used elsewhere. This doesn’t change behavior. --- ChangeLog| 8 lib/alignalloc.h |

[PATCH 6/7] xalloc: port to Cheri, strict C23, realloc null

* lib/xmalloc.c [__CHERI_PURE_CAPABILITY__]: Include . (xrealloc, xreallocarray): Support Cheri. Avoid undefined behavior in strict C23. Work better on platforms where realloc (p, 0) returns a null pointer --- ChangeLog | 6 ++ lib/xmalloc.c | 28 2 files ch

[PATCH 4/7] ialloc: fix realloc-gnu dependency

* modules/ialloc (Depends-on): Remove realloc-gnu, as ialloc.c does not depend on GNU semantics for realloc. --- ChangeLog | 4 modules/ialloc | 1 - 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index f8209aff70..0a74a6483c 100644 --- a/ChangeLog ++

[PATCH 5/7] reallocarray: simplify

* lib/reallocarray.c (reallocarray): Use simpler workaround for realloc glitch, which does not involve malloc. * modules/reallocarray (Depends-on): Remove malloc-posix. --- ChangeLog| 7 +++ lib/reallocarray.c | 14 -- modules/reallocarray | 1 - 3 files changed, 11

[PATCH 3/7] backupfile: fix irealloc dependency

* modules/backupfile (Depends-on): Depend on irealloc, not realloc-gnu, as the code now uses irealloc not realloc and does not depend on GNU semantics anyway. --- ChangeLog | 5 + modules/backupfile | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/Chan

[PATCH 2/7] group-member: fix malloc-gnu dependency

* modules/group-member (Depends-on): Depend on malloc-gnu, not realloc-gnu, since the code uses malloc not realloc. --- ChangeLog| 4 modules/group-member | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 8c89713ebf..93b50bde70 10064

Re: [PATCH] tests/test-crc.c: New tests for future optimised implementation.

Sam Russell wrote: > I think we are massively overengineering this. We shouldn't need to > future-proof tests for changes that *might* be added in the future, and > having 32x32 hashes in a table at the start of the test is not a big deal > (it took less than a second to generate and it'll take the