Re: [PATCH 2/2] Don't allocate another header when merging chunks

[Jeff Johnston <jjohnstn@redhat.com>]

I think that the check for MALLOC_MINCHUNK should still apply.  Do you
agree?

-- Jeff J.

On Tue, Aug 30, 2022 at 9:57 AM Torbjörn SVENSSON <
torbjorn.svensson@foss.st.com> wrote:

> In the nano version of malloc, when the last chunk is to be extended,
> there is no need to acount for the header again as it's already taken
> into account in the overall "alloc_size" at the beginning of the
> function.
>
> Contributed by STMicroelectronics
>
> Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
> ---
>  newlib/libc/stdlib/nano-mallocr.c | 4 ----
>  1 file changed, 4 deletions(-)
>
> diff --git a/newlib/libc/stdlib/nano-mallocr.c
> b/newlib/libc/stdlib/nano-mallocr.c
> index 43eb20e07..b2273ba60 100644
> --- a/newlib/libc/stdlib/nano-mallocr.c
> +++ b/newlib/libc/stdlib/nano-mallocr.c
> @@ -328,10 +328,6 @@ void * nano_malloc(RARG malloc_size_t s)
>                 /* The last free item has the heap end as neighbour.
>                  * Let's ask for a smaller amount and merge */
>                 alloc_size -= p->size;
> -               alloc_size = ALIGN_SIZE(alloc_size, CHUNK_ALIGN); /* size
> of aligned data load */
> -               alloc_size += MALLOC_PADDING; /* padding */
> -               alloc_size += CHUNK_OFFSET; /* size of chunk head */
> -               alloc_size = MAX(alloc_size, MALLOC_MINCHUNK);
>
>                 if (sbrk_aligned(RCALL alloc_size) != (void *)-1)
>                 {
> --
> 2.25.1
>
>