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.


"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â.


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