This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [COMMITTED] malloc/malloc.c : Remove nested function mi_arena.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]