Date: Fri, 31 Oct 2025 10:40:02 +0100
Hi Marc,
On Fri, Oct 31, 2025 at 01:49:32AM +0000, Marc Edouard Gauthier via Std-Proposals wrote:
> > > > We could add this:
> > > >
> > > > realloc(3) shall preserve the alignment of a block allocated
> > > > previously by aligned_alloc(3).
> > > >
> > > > Please let me know if you want something like this, and we can
> > > > discuss on writing a proposal.
> > >
> > > Yes, I'd like that, but I don't *need* that because there's an
> > > alternative. So question should be first to malloc() maintainers: would this be doable?
> >
> > Thanks! I've also sent an email to glibc and musl about this (and again, also CCd you and others).
>
> Requiring preservation of alignment sounds nice but may not be universally desirable.
> It will definitely break various simple allocator implementations, especially in the embedded world.
> There may be simply no space to store alignment when each allocated block is separated by a single 32-bit word providing the sizes of this and the previous block, and various other such schemes. Asking an embedded allocator running on machines with limited memory resources to waste another 32-bits per allocated block is a no-go.
Hmmm. And I assume a separate arena for aligned allocations would also
be too much waste so also impossible. Maybe they could just check the
actual alignment of a block, and allocate the same one with realloc(3).
That could mean overaligning, but it wouldn't require estra metadata
memory.
Alternatively, we could add this requirement in POSIX, but don't require
it in ISO C. That would be useful in a large number of cases.
Have a lovely day!
Alex
On Fri, Oct 31, 2025 at 01:49:32AM +0000, Marc Edouard Gauthier via Std-Proposals wrote:
> > > > We could add this:
> > > >
> > > > realloc(3) shall preserve the alignment of a block allocated
> > > > previously by aligned_alloc(3).
> > > >
> > > > Please let me know if you want something like this, and we can
> > > > discuss on writing a proposal.
> > >
> > > Yes, I'd like that, but I don't *need* that because there's an
> > > alternative. So question should be first to malloc() maintainers: would this be doable?
> >
> > Thanks! I've also sent an email to glibc and musl about this (and again, also CCd you and others).
>
> Requiring preservation of alignment sounds nice but may not be universally desirable.
> It will definitely break various simple allocator implementations, especially in the embedded world.
> There may be simply no space to store alignment when each allocated block is separated by a single 32-bit word providing the sizes of this and the previous block, and various other such schemes. Asking an embedded allocator running on machines with limited memory resources to waste another 32-bits per allocated block is a no-go.
Hmmm. And I assume a separate arena for aligned allocations would also
be too much waste so also impossible. Maybe they could just check the
actual alignment of a block, and allocate the same one with realloc(3).
That could mean overaligning, but it wouldn't require estra metadata
memory.
Alternatively, we could add this requirement in POSIX, but don't require
it in ISO C. That would be useful in a large number of cases.
Have a lovely day!
Alex
-- <https://www.alejandro-colomar.es> Use port 80 (that is, <...:80/>).
Received on 2025-10-31 09:40:13
