This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [COMMITTED] malloc/malloc.c : Remove nested function mi_arena.
- From: ludo at gnu dot org (Ludovic CourtÃs)
- To: libc-alpha at sourceware dot org
- Date: Mon, 26 May 2014 21:21:47 +0200
- Subject: Re: [COMMITTED] malloc/malloc.c : Remove nested function mi_arena.
- Authentication-results: sourceware.org; auth=none
- References: <5383536D dot 5010601 at redhat dot com>
"Carlos O'Donell" <carlos@redhat.com> skribis:
> We do this because it's harder to debug nested functions,
> and it allows non-GNU compilers to compile this code, and
> this code is not performance critical.
>
> The resulting code is ~100 bytes larger because the compiler
> has to handle the function arguments and pointers to size_t
> objects. This code, and in particular calling malloc_info, is
> not considered in the hot path of average applications.
Seems to me like it meets the criteria for rejection that Roland
suggested:
http://sourceware.org/ml/libc-alpha/2014-05/msg00707.html
> +static inline void
> +mi_arena (mstate ar_ptr,
> + FILE *fp,
> + size_t *total_nblocks,
> + size_t *total_nfastblocks,
> + size_t *total_avail,
> + size_t *total_fastavail,
> + size_t *total_system,
> + size_t *total_max_system,
> + size_t *total_aspace,
> + size_t *total_aspace_mprotect)
[...]
> - mi_arena (ar_ptr);
> + mi_arena (ar_ptr, fp, &total_nblocks, &total_nfastblocks, &total_avail,
> + &total_fastavail, &total_system, &total_max_system,
> + &total_aspace, &total_aspace_mprotect);
> ar_ptr = ar_ptr->next;
> }
Anyone claiming that this improves readability?
Ludoâ.