Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zfr5d0a0.fsf@oldenburg.str.redhat.com>
Date: Fri, 28 Jun 2024 08:55:19 +0200
From: Florian Weimer <fweimer@...hat.com>
To: enh <enh@...gle.com>
Cc: libc-coord@...ts.openwall.com,  Zijun Zhao <zijunzhao@...gle.com>
Subject: Re: aligned_realloc()

> 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.

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.