On 4/18/21 5:04 PM, Bruno Haible wrote:
Paul Eggert wrote:
I installed the attached instead, as this is simpler.
And I'm already starting to wonder whether testing for ptrdiff_t
overflow was such a good idea. I installed the attached further patch to
try to pacify GCC diagnostics about them.
This effectively replaces xnmalloc, which perhaps should be deprecated.
The name xreallocarray should be easier to remember now that
reallocarray is a standard GNU function.
* lib/xalloc.h [GNULIB_XALLOC]: Do not include xalloc-oversized.h.
(xnmalloc, xnrealloc, x2nrealloc): Simplify by using xreal
* lib/safe-alloc.c: Do not include xalloc-oversized.h.
(safe_alloc_alloc_n, safe_alloc_realloc_n):
Use reallocarray to check for size or ptrdiff_t overflow.
* modules/reallocarray (License): Switch from LGPL to LGPLv2+, as
this is needed for safe-alloc and anyway is more appropriate for
this librar
* lib/xalloc-oversized.h (xalloc_count_t): Remove; no longer
needed and was evidently error-prone anyway.
(xalloc_oversized): Omit some over-optimization that caused
SIZE_MAX to not be treated as too large (the Gnulib convention) on
unusual platforms where PTRDIFF_MAX == SIZE_MAX. This change
shou
The old implementation assumed that all pointers use the same
internal representation, but the C standard doesn’t guarantee
this. Use void * (pointer) not void ** (pointer-to-pointer) for
the internal functions’ API. The internal functions now return
NULL if and only if they failed, and the macro
* modules/calloc-gnu (License): Change from GPL to LGPLv2+.
The old value was evidently a longstanding typo, and calloc
will be needed by LGPLv2+ modules that will want to rely
on GNU behavior.
---
ChangeLog | 6 ++
modules/calloc-gnu | 2 +-
2 files changed, 7 insertions(+), 1 deleti
* lib/group-member.c, modules/group-member:
Simplify similarly to backupfile.
---
ChangeLog| 4
lib/group-member.c | 6 ++
modules/group-member | 2 +-
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index e00a5b7c8..aff0e87fc 100644
---
* lib/backupfile.c: Do not include xalloc-oversized.h.
(numbered_backup): Simplify now that realloc will do the right
thing about ptrdiff_t overflow.
* modules/backupfile (Depends-on): Add realloc-gnu;
remove xalloc-oversized.
---
ChangeLog | 7 +++
lib/backupfile.c | 3 +--
modules
* doc/safe-alloc.texi: Clarify that reallocating an array appends
uninitialized storage. Say ‘sizeof *p’ rather than ‘sizeof(*p)’
which would need a space before the paren to follow GNU style.
---
ChangeLog | 5 +
doc/safe-alloc.texi | 14 +-
2 files changed, 14 inserti
Paul Eggert wrote:
> I installed the attached instead, as this is simpler.
Thanks!
> If there are
> problems with PTRDIFF_MAX + 1, the test program might thrash or maybe
> even crash the kernel, but that's good enough since there shouldn't be
> problems.
Agree.
Bruno
On 4/16/21 7:53 PM, Bruno Haible wrote:
+ malloc, realloc: fix recently-introduced #undef typos
That must have been more than a typo? It must have been an endless recursion?
Yes, they were typos that caused infloops. But little harm done; I don't
think they escaped into any distribution
On 4/18/21 1:23 PM, Bruno Haible wrote:
If we put the test in a module that is marked as
Status:
privileged-test
It shouldn't require root access to test.
I installed the attached instead, as this is simpler. If there are
problems with PTRDIFF_MAX + 1, the test program might thrash
Paul Eggert wrote:
> > For example, if my package never calls malloc (0) but desires portability
> > to native Windows, would I want that *every* malloc call on *all*
> > non-glibc platforms goes through hoops before it reaches the malloc()
> > function in libc?
>
> I would want that, yes, because
On 4/18/21 5:11 AM, Bruno Haible wrote:
Paul Eggert wrote:
Come to think of it, why do we have both malloc-gnu and malloc-posix
modules (and similarly for calloc and realloc)?
Package owners had two decisions to make:
"Does my package ever call malloc (0)? - If yes, I need 'malloc-gnu'."
Hi Paul,
> > How about extending the unit test (tests/test-malloc-gnu.c) accordingly?
>
> Won't that raise the possibility of the tests being too expensive, in
> case the C library actually attempts to allocate PTRDIFF_MAX + 1 bytes?
In those cases where our code has a bug and the xalloc_oversi
On 4/18/21 5:13 AM, Bruno Haible wrote:
How about extending the unit test (tests/test-malloc-gnu.c) accordingly?
Won't that raise the possibility of the tests being too expensive, in
case the C library actually attempts to allocate PTRDIFF_MAX + 1 bytes?
(I'm looking at you, 64-bit Hurd. :-)
On Tue, Apr 6, 2021 at 1:30 PM Bruno Haible wrote:
> Paul Eggert wrote:
> > Yes, that would be portable. But that cast indicates another problem
> > with the API. It should return void *, not void const * (think of strchr
> > as the model here).
>
> strchr is a bad model here: You pass it a pointe
On Tue, Apr 6, 2021 at 4:04 PM Bruno Haible wrote:
>
> I wrote:
> > So far we have been lacking type-casts that warn for invalid use;
> > it is well possible that with the PSPP macros (or with Marc's approach
> > of _Generic), we can design a type-safe wrapper around gl_list.h
>
> Here is a simpli
On 4/18/21 5:13 AM, Bruno Haible wrote:
* m4/realloc.m4 (_AC_FUNC_REALLOC_IF):
Don’t start with a newline.
This is not very robust. We usually don't care about newlines or useless
indentation in the generated configure.ac any more.
Yes, I made that change only because I ran into some shell s
Hi Paul,
> * m4/realloc.m4 (_AC_FUNC_REALLOC_IF):
> Don’t start with a newline.
This is not very robust. We usually don't care about newlines or useless
indentation in the generated configure.ac any more. Therefore future
edits may reintroduce a newline here. It would be more robust to change
> In glibc 2.30 and later, malloc, realloc and calloc reject
> attempts to create objects larger than PTRDIFF_MAX bytes.
> This patch changes malloc-gnu etc. to support this behavior
> on non-GNU hosts.
How about extending the unit test (tests/test-malloc-gnu.c) accordingly?
Bruno
Paul Eggert wrote:
> Come to think of it, why do we have both malloc-gnu and malloc-posix
> modules (and similarly for calloc and realloc)?
Package owners had two decisions to make:
"Does my package ever call malloc (0)? - If yes, I need 'malloc-gnu'."
"Does my package attempt portability to
> * doc/posix-functions/calloc.texi:
> * doc/posix-functions/malloc.texi:
> * doc/posix-functions/realloc.texi:
> Mention ptrdiff_t issues, and go into more detail about what
> the gnu extension module does.
The patch dropped the list of affected platforms. However this list is
important so that
This gets closer to a systematic naming of the *.m4 files of header
replacements. Only stdint.m4 and inttypes.m4 are not aligned.
2021-04-18 Bruno Haible
More systematic file naming.
* m4/ctype_h.m4: Renamed from m4/ctype.m4.
* m4/threads_h.m4: Renamed from m4/threads.
I wrote:
> The problem is that the macro gl_STDIO_H_REQUIRE_DEFAULTS must only be
> invoked,
> never AC_REQUIREd. Hence all gl_STDIO_MODULE_INDICATOR invocations must also
> only be invoked, never AC_REQUIREd.
This deserves to be documented.
2021-04-18 Bruno Haible
Add comments afte
2021-04-18 Bruno Haible
doc: Update for FreeBSD 13.0/arm64.
* doc/posix-headers/stdint.texi: Mention FreeBSD 13 bug.
* m4/stdint.m4: Update comment.
diff --git a/doc/posix-headers/stdint.texi b/doc/posix-headers/stdint.texi
index 6775bea..784799b 100644
--- a/doc/posix-
26 matches
Mail list logo
