Paul Eggert wrote:
> I don't see why not, at least on platforms of interest to Gnulib. On systems
> that provide no native way to do an aligned allocation, we merely keep
> calling
> malloc with suitable arguments until we get a pointer that is suitably
> aligned.
> We then free all the
On Tue, Jul 21, 2020 at 5:18 PM Paul Eggert wrote:
>
> On 7/21/20 8:51 AM, Florian Weimer wrote:
> > The official aligned_alloc produces pointers compatible with free.
> > This module cannot do that.
>
> I don't see why not, at least on platforms of interest to Gnulib. On systems
> that provide
On 7/21/20 8:51 AM, Florian Weimer wrote:
The official aligned_alloc produces pointers compatible with free.
This module cannot do that.
I don't see why not, at least on platforms of interest to Gnulib. On systems
that provide no native way to do an aligned allocation, we merely keep calling
I wrote:
> there is hope that some systems (maybe native Windows?)
> may get aligned_alloc sooner than posix_memalign.
Oh, I was too naïve. Citing Microsoft [1][2]:
"aligned_alloc() will probably never be implemented, as C11 specified it
in a way that’s incompatible with our implementation
Hi Paul,
> C11 and C++17 have aligned_alloc, which Emacs uses in preference to
> posix_memalign.
Just noticed it as well, when looking at the glibc documentation [1].
Patch below.
> I suggest preferring aligned_alloc to
> posix_memalign since aligned_alloc should be available on more systems
* Paul Eggert:
> Also, how about naming the new module 'aligned-alloc' and having it
> implement aligned_alloc? That would make for more-seamless
> integration.
The official aligned_alloc produces pointers compatible with free.
This module cannot do that.
Thanks,
Florian
On 7/21/20 1:47 AM, Bruno Haible wrote:
The posix_memalign and memalign functions only help on those platforms where
they exist. It's not possible to emulate posix_memalign or memalign when they
are not present, because when malloc() returned p, we can call free (p)
but not free (p+4) or free
Jeffrey Walton wrote:
> > And glibc aligns malloc()
> > results to 8 bytes on most 32-bit platforms.
>
> I believe the runtime is required to return a pointer aligned for the
> largest C type on the system. On x86 that's 16 bytes due to the xmm
> datatypes.
Right. The malloc() alignment on
On Tue, Jul 21, 2020 at 7:24 AM Bruno Haible wrote:
>
> > Checkout https://forum.kde.org/viewtopic.php?p=66274 for some info on
> > detection of posix_memalign.
>
> It's well-known that you can't use standards symbols like __STDC_VERSION__
> or _XOPEN_SOURCE for hardly anything. We wouldn't have
Hi Jeffrey,
> Checkout https://forum.kde.org/viewtopic.php?p=66274 for some info on
> detection of posix_memalign.
It's well-known that you can't use standards symbols like __STDC_VERSION__
or _XOPEN_SOURCE for hardly anything. We wouldn't have hundreds of
AC_CHECK_FUNC calls in gnulib/m4/ if
On Tue, Jul 21, 2020 at 4:48 AM Bruno Haible wrote:
>
> In new gnulib code, I need to allocate memory blocks through malloc() but with
> a 16-bytes alignment.
>
> The posix_memalign and memalign functions only help on those platforms where
> they exist. It's not possible to emulate posix_memalign
In new gnulib code, I need to allocate memory blocks through malloc() but with
a 16-bytes alignment.
The posix_memalign and memalign functions only help on those platforms where
they exist. It's not possible to emulate posix_memalign or memalign when they
are not present, because when malloc()
On 64-bit native Windows, PRIPTR_PREFIX comes out as "l", which produces
wrong output of intptr_t values through *printf. It should be "ll" instead.
2020-07-21 Bruno Haible
inttypes: Fix PRI*PTR and SCN*PTR on 64-bit native Windows.
* m4/inttypes.m4 (gl_INTTYPES_PRI_SCN): On
The gl_PRINTF_DIRECTIVE_N test uses type 'uintptr_t'. While it happens to be
present from including or , it's more future-proof to
explicitly include .
2020-07-21 Bruno Haible
printf-posix: Make an autoconf test more future-proof.
* m4/printf.m4 (gl_PRINTF_DIRECTIVE_N):
14 matches
Mail list logo
