Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240724184013.GG10433@brightrain.aerifal.cx>
Date: Wed, 24 Jul 2024 14:40:13 -0400
From: Rich Felker <dalias@...c.org>
To: libc-coord@...ts.openwall.com
Cc: Florian Weimer <fweimer@...hat.com>, enh <enh@...gle.com>,
	Zijun Zhao <zijunzhao@...gle.com>
Subject: Re: aligned_realloc()

On Fri, Jun 28, 2024 at 11:02:49PM +0100, Paul Eggert wrote:
> On 6/28/24 07:55, Florian Weimer wrote:
> >I don't think many allocators keep track of alignment at time of
> >allocation explicitly, so I don't see there is much that can be done
> >except effectively ignoring the original allignment for the purposes of
> >reallocation.
> 
> The memory allocator needn't track the original alignment
> explicitly. Instead, realloc, when moving data, can allocate
> replacement memory with the same alignment as the incoming pointer.
> Although this would likely mean more fragmentation, it might not be
> all that bad in practice, at least for people who care about
> alignment more than fragmentation.

This would be rather unfortunate if the object passed just happened to
have address 0x80000000 (or analogous for however many bits of a
64-bit address space are usable). Certainly could happen by chance
when the original requested allocation was only 4k or 64k or
something.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.