no on AIX.
> +aix*)gl_cv_func_aligned_alloc_works="guessing no" ;;
The variable name is wrong.
2024-10-31 Bruno Haible
posix_memalign: Fix configure test (regression yesterday).
* m4/posix_memalign.m4 (gl_FUNC_POSIX_MEMALIGN): Fix typo in comment.
Fix variab
code tests for errno == ENOMEM (whether rightly or
wrongly). That's why other Gnulib functions in a similar situation
(e.g., reallocarray) use ENOMEM.
For example, it'd be odd if posix_memalign (&p, 2, SIZE_MAX - 1)
returned ENOMEM but posix_memalign (&p, 2, SIZE_MAX) return
On Wed, Oct 30, 2024 at 3:51 PM Paul Eggert wrote:
>
> * lib/posix_memalign.c: Include stdckdint.h.
> (posix_memalign): Test for overflow more straightforwardly,
> and more portably to unlikely platforms where SIZE_MAX <= INT_MAX.
> Treat a zero size as if it were
* lib/posix_memalign.c: Include stdckdint.h.
(posix_memalign): Test for overflow more straightforwardly,
and more portably to unlikely platforms where SIZE_MAX <= INT_MAX.
Treat a zero size as if it were alignment.
* m4/posix_memalign.m4 (gl_FUNC_POSIX_MEMALIGN):
* tests/test-posix_memalig
Paul Eggert wrote:
> It should be better for OpenBSD 6.2+ when doing cross-builds, because it
> guesses that the bug is fixed there.
Oh, I see: the main part was the change of the cross-compilation guess,
and the part with sizeof (void *) is meant as a no-op.
I was confused by the part with size
On 2024-10-27 10:13, Bruno Haible wrote:
I don't understand this ChangeLog entry. If it is fixed in OpenBSD >= 6.2,
it's a "port better to OpenBSD <= 6.1", no?
It should be better for OpenBSD 6.2+ when doing cross-builds, because it
guesses that the bug is fixed there.
It shouldn't affect Op
Paul Eggert wrote:
> + 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+.
I don't understand this ChangeLog entry. If it is fix
dex 6b65268fa2..a03100eacb 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
2024-10-26 Paul Eggert
+ 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 fi
+1,8 @@
2024-10-26 Paul Eggert
+ posix_memalign-tests: fix message typo
+ * tests/test-posix_memalign.c (main): Fix diagnostic typo.
+
aligned_alloc: document glibc bug 32301
* doc/posix-functions/aligned_alloc.texi:
* doc/posix-functions/posix_memalign.texi
- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,9 @@
2023-11-06 Paul Eggert
+ posix_memalign-tests: port to CHERI-64
+ * tests/test-posix_memalign.c (main):
+ Don’t assume sizeof (void *) <= 8.
+
mcel-tests: fix read overrun in test case
* tests/test-mcel.c (main):
Here comes the module 'posix_memalign'. On OpenBSD 6.0 and 6.1,
void *p;
posix_memalign (&p, 32, 2406)
produces a pointer p that is not a multiple of 32. It's fixed in OpenBSD 6.2.
2020-11-03 Bruno Haible
posix_memalign: Add tests.
* tests/test-po
Eric Blake wrote:
> > We have a 'pagealign_alloc' module that does not waste memory.
>
> Alas, pagealign_alloc is currently GPLv3+, although if libvirt were to
> use it in place of posix_memalign, it would have to be LGPLv2+. It
> looks like Jim, Paul, and Bruno are
On 11/25/2011 04:24 PM, Bruno Haible wrote:
> Eric Blake wrote:
>>>> If gnulib would give
>>>> us posix_memalign on mingw, we could nuke this #if altogether.
>>>
>>> That's pretty difficult (unless you also add a posix_memalign_free)
>>> b
[Dropping libvir-list]
Peter O'Gorman wrote:
> Many of these systems have valloc(3) which could be used for this purpose.
Yes, but gnulib's pagealign_alloc() function is less wasteful that the
valloc() function that some systems have. E.g. in OpenBSD:
void *
valloc(size_t i)
{
long valsi
[Dropping libvir-list]
Eric Blake wrote:
> >> If gnulib would give
> >> us posix_memalign on mingw, we could nuke this #if altogether.
> >
> > That's pretty difficult (unless you also add a posix_memalign_free)
> > because at the time posix_memalign retur
15 matches
Mail list logo
