|
|
Message-ID: <20251101010209.GS1827@brightrain.aerifal.cx>
Date: Fri, 31 Oct 2025 21:02:09 -0400
From: Rich Felker <dalias@...c.org>
To: Alejandro Colomar <alx@...nel.org>
Cc: musl@...ts.openwall.com, "A. Wilcox" <AWilcox@...cox-tech.com>,
Lénárd Szolnoki <cpp@...ardszolnoki.com>,
Thorsten Glaser <tg@...bsd.de>,
Collin Funk <collin.funk1@...il.com>
Subject: Re: [RFC] add realloci() and reallocarrayi()
On Fri, Oct 31, 2025 at 03:01:58PM +0100, Alejandro Colomar wrote:
> They are realloc(3) variants that work in-place. They change the size
> of a block of memory, without affecting the lifetime of the object.
> It requires a non-null pointer, unlike realloc(3), as it can't create
> a new object (it doesn't return a pointer).
>
> Cc: "A. Wilcox" <AWilcox@...cox-tech.com>
> Cc: Lénárd Szolnoki <cpp@...ardszolnoki.com>
> Cc: Thorsten Glaser <tg@...bsd.de>
> Cc: Collin Funk <collin.funk1@...il.com>
> Signed-off-by: Alejandro Colomar <alx@...nel.org>
> ---
>
> Hi,
>
> I have not tested this patch (not even tried building yet). It's just
> an initial draft, requesting comments about the overall idea.
>
> So far, I've only implemented this in the mallocng implementation, as
> the oldmalloc implementation was too weird for me to fully understand.
> Do we need an old implementation too?
>
>
> Have a lovely day!
> Alex
>
> include/stdlib.h | 2 ++
> ldso/dynlink.c | 1 +
> src/aio/aio.c | 1 +
> src/exit/atexit.c | 1 +
> src/ldso/dlerror.c | 1 +
> src/locale/dcngettext.c | 1 +
> src/locale/duplocale.c | 1 +
> src/locale/freelocale.c | 1 +
> src/locale/locale_map.c | 1 +
> src/locale/newlocale.c | 1 +
> src/malloc/mallocng/glue.h | 1 +
> src/malloc/mallocng/realloc.c | 8 +-------
> src/malloc/mallocng/realloci.c | 26 ++++++++++++++++++++++++++
> src/malloc/reallocarrayi.c | 13 +++++++++++++
> src/malloc/realloci.c | 7 +++++++
> src/process/fdop.h | 1 +
> src/thread/pthread_atfork.c | 1 +
> src/thread/sem_open.c | 1 +
> src/time/__tz.c | 1 +
> 19 files changed, 63 insertions(+), 7 deletions(-)
> create mode 100644 src/malloc/mallocng/realloci.c
> create mode 100644 src/malloc/reallocarrayi.c
> create mode 100644 src/malloc/realloci.c
>
> diff --git a/include/stdlib.h b/include/stdlib.h
> index 475190bf..577b7172 100644
> --- a/include/stdlib.h
> +++ b/include/stdlib.h
> @@ -148,6 +148,8 @@ int clearenv(void);
> #define WCOREDUMP(s) ((s) & 0x80)
> #define WIFCONTINUED(s) ((s) == 0xffff)
> void *reallocarray (void *, size_t, size_t);
> +int realloci (void *, size_t);
> +int reallocarrayi (void *, size_t);
> void qsort_r (void *, size_t, size_t, int (*)(const void *, const void *, void *), void *);
> #endif
>
> diff --git a/ldso/dynlink.c b/ldso/dynlink.c
> index 715948f4..a882c5c1 100644
> --- a/ldso/dynlink.c
> +++ b/ldso/dynlink.c
> @@ -35,6 +35,7 @@ static size_t ldso_page_size;
> #define malloc __libc_malloc
> #define calloc __libc_calloc
> #define realloc __libc_realloc
> +#define realloci __libc_realloci
> #define free __libc_free
These gratuitous changes all over are not needed. realloci would never
be used internally so there's no reason to remap it or make a
libc-internal version of it. Same reason as for aligned_alloc, etc.
which aren't macro-redirected.
> diff --git a/src/malloc/mallocng/realloc.c b/src/malloc/mallocng/realloc.c
> index 18769f42..92f8eea5 100644
> --- a/src/malloc/mallocng/realloc.c
> +++ b/src/malloc/mallocng/realloc.c
> @@ -15,15 +15,9 @@ void *realloc(void *p, size_t n)
> unsigned char *start = g->mem->storage + stride*idx;
> unsigned char *end = start + stride - IB;
> size_t old_size = get_nominal_size(p, end);
> - size_t avail_size = end-(unsigned char *)p;
> void *new;
>
> - // only resize in-place if size class matches
> - if (n <= avail_size && n<MMAP_THRESHOLD
> - && size_to_class(n)+1 >= g->sizeclass) {
> - set_size(p, end, n);
> - return p;
> - }
> + if (realloci(p, n) == 0) return p;
This is a namespace violation. realloc can't depend on realloci.
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.