Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACb0b4nXTXOPz6XMDihurz9M7TP9TKH39YYdszoBcOgfWhdLCw@mail.gmail.com>
Date: Fri, 28 Jun 2024 22:14:02 +0100
From: Jonathan Wakely <jwakely@...hat.com>
To: libc-coord@...ts.openwall.com
Cc: Jonathan Wakely <jwakely.gcc@...il.com>, enh <enh@...gle.com>, 
	Zijun Zhao <zijunzhao@...gle.com>
Subject: Re: aligned_realloc()

On Fri, 28 Jun 2024 at 20:41, Florian Weimer <fweimer@...hat.com> wrote:
>
> * Jonathan Wakely:
>
> >> 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.
>
> Does the default allocator have to call ::operator new(std::size_t)?

Yes, although it doesn't have to call operator new 1:1, instead
std::allocator can cache memory obtained from operator new, manage its
own heap etc. In practice, modern std::allocator implementations don't
do that, they just call straight through to new/delete for every
allocate/deallocate call.

> Is this an interposable interface, similar to malloc?

Yes.

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.