[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJgzZopO=XFtjU3JV-Kkt8Yixsj9nycYQBDEdfbjqvGrmC89RA@mail.gmail.com>
Date: Fri, 28 Jun 2024 14:44:28 -0400
From: enh <enh@...gle.com>
To: Florian Weimer <fweimer@...hat.com>
Cc: libc-coord@...ts.openwall.com, Zijun Zhao <zijunzhao@...gle.com>
Subject: Re: aligned_realloc()
On Fri, Jun 28, 2024 at 2:55 AM 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.
yeah, ours doesn't either.
> 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.
the only other weird realloc() variant i came across was this in macOS
and FreeBSD (only; not Net or Open):
The reallocf() function is identical to the realloc() function, except
that it will free the passed pointer when the requested memory cannot
be allocated. This is a FreeBSD specific API designed to ease the
problems with traditional coding styles for realloc() causing memory
leaks in libraries.
> 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.
>
> Thanks,
> Florian
>
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.
