This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Refactor malloc (x * sizeof (t) to XNMALLOC (x, t).
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 31 Oct 2013 22:42:50 +0100
- Subject: Re: [PATCH] Refactor malloc (x * sizeof (t) to XNMALLOC (x, t).
- Authentication-results: sourceware.org; auth=none
- References: <20131031164614 dot GA28117 at domone dot podge> <5272C4B7 dot 10104 at cs dot ucla dot edu>
On Thu, Oct 31, 2013 at 01:59:35PM -0700, Paul Eggert wrote:
> On 10/31/2013 09:46 AM, OndÅej BÃlka wrote:
>
> > +#define XNMALLOC(e, tp) (tp *) malloc ((e) * sizeof (tp))
>
> Don't we need something similar for realloc?
>
Will come in next iteration.
> It needs another parentheses around the entire definiens.
>
> Better yet, why not a function instead of a macro?
A macro saves cast in more cases than adding cast to change type.
Both approaches are possible but I would prefer sticking to one.
Second reason that I picked macro was because I assumed that gcc does
not inline functions with inline assembly. A gcc does it which changes
situation a bit.
> E.g., something like this in libc-internal.h:
>
> /* Return the address of an array of N objects, each of nonzero
> size S, or NULL (setting errno) if the allocation fails. */
>
> inline void *
> nmalloc (size_t n, size_t s)
> {
> return malloc (n <= SIZE_MAX / s ? n * s : SIZE_MAX);
> }
>
> That way, instead of this:
>
> result = XNMALLOC (step_cnt, struct __gconv_step);
>
> a caller can write this:
>
> result = nmalloc (step_cnt, sizeof *result);
>
> with simpler semantics, and with less churn later if 'result' changes
> its type.