[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240724201511.GI10433@brightrain.aerifal.cx>
Date: Wed, 24 Jul 2024 16:15:14 -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 Wed, Jul 24, 2024 at 01:03:36PM -0700, Paul Eggert wrote:
> On 2024-07-24 11:40, Rich Felker wrote:
> >>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
>
> Of course, but the chances are low.
Not very low.
> And if you're worried about it,
> don't let malloc hand out those rare addresses. That wouldn't be
> hard.
In order never to have "alignment stored as part of the address" be
excessive, you'd need to always have the first bit after the
requested, or at least max acceptable, alignment be a 1. I think
you'll find that's a lot more constraining on what part of the address
space you can use than you'd expect. And all of that not just for the
sake of overaligned allocations, which are very rare and only used by
a tiny amount of software, but for the sake of this hypothetical,
rarely-useful proposed future API for overaligned allocations. This
just does not sound like a good tradeoff between constraints and
value.
Rich
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.
