[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH6eHdRrGhdHuMHqrMTpgTmFh5ki903D+Kxt7+Naq2-kS63R+A@mail.gmail.com>
Date: Fri, 28 Jun 2024 10:34:21 +0100
From: Jonathan Wakely <jwakely.gcc@...il.com>
To: libc-coord@...ts.openwall.com
Cc: enh <enh@...gle.com>, Zijun Zhao <zijunzhao@...gle.com>
Subject: Re: aligned_realloc()
On Fri, 28 Jun 2024 at 07:55, Florian Weimer <fweimer@...hat.com> wrote:
>
> > C23 doesn't say anything about alignment when describing realloc(). it
> > might be nice to assume that "The realloc function deallocates the old
> > object pointed to by ptr and returns a pointer to a new
> > object that has the size specified by size" actually means "The
> > realloc function deallocates the old object pointed to by ptr and
> > returns a pointer to a new object that has the size specified by size,
> > and the same alignment that the old object had", since that's
> > presumably what anyone making the call means, but i don't even know
> > what our allocator does.
>
> 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. I don't believe there is lots of desire to change that.
>
> The more general solution would be a function that fails if the
> allocation cannot be resized in place. This necessarily preserves
> alignment, and the caller can create the new allocation with the
> required alighment.
>
> The signature could look like this:
>
> size_t realloc_no_move (void *ptr, size_t b, size_t m, size_t x_min,
> size_t x_max);
>
> PTR must not be null. The function changes the size of the object to
> m * x + b, where x_min ≤ x ≤ x_max if such an x exists, or leaves
> the size of the object unchanged. It returns the new size of the
> object.
>
> It's not ideal because recovering the concrete x used may require a
> division, but I assume it's usually a division by constant, so not too
> costly. Returning the x value is problematic if the existing allocation
> is not within the right arithmetic progression.
>
> This would also be helpful in the implementation of data structures such
> as std::vector, where in-place resizing and moving allocations require
> different execution paths.
Probably not, because std::vector goes through the C++ Allocator
interface, which is very unlikely to expose something like this.
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.
