Thanks for all those fixes (and the detailed reports!).
> 2021-05-09 Bruno Haible
>
> {malloc,realloc,calloc}-gnu: Fix autoconf macro (regression 2021-04-18).
Even after this is fixed, I see a test failure (building the newest m4)
on AIX in 64-bit mode: test-calloc-gnu fails with exit code 1.
Looking at the details: The configure output has
Hi Paul,
On 2021-04-18 you replied:
> > if test $REPLACE_REALLOC = 0; then
> > _AC_FUNC_REALLOC_IF([], [REPLACE_REALLOC=1])
> > fi
>
> I confess I don't like the style as much: it makes the shell code a bit
> less readable, at least to me. But it appears that this style isn't
> needed a
Paul Eggert wrote:
> I installed the attached patches into Gnulib to make its malloc
> replacements ptrdiff_t safe.
When testing m4-1.4.18b on IRIX 6.5, I get a test failure:
FAIL: test-reallocarray
Let's look in detail:
$ ./test-reallocarray ; echo $?
2
There is a call
p = realloc (NULL, 2
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.
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/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 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
I installed the attached patches into Gnulib to make its malloc
replacements ptrdiff_t safe. This should help us move in a direction
where we can use idx_t (which is signed and therefore safer) for sizes
and indexes, instead of using size_t.
In creating these patches I found a reasonable amoun
17 matches
Mail list logo
