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: Rich Felker <dalias at libc dot org>
- To: Ludovic CourtÃs <ludo at gnu dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 27 May 2014 23:15:26 -0400
- 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> <87vbssxs50 dot fsf at gnu dot org>
On Mon, May 26, 2014 at 09:21:47PM +0200, Ludovic CourtÃs wrote:
> "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)
Despite my being in favor of eliminating nested functions, I'm in
complete agreement. This kind of mechanical transformation with
pointers to all of the outer function's locals is utterly hideous to
read, and makes the compiler's work much more difficult.
I'm in favor of the earlier proposal to inline the code directly.
Rich