This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 1/2] Add nmalloc and nrealloc
- From: Florian Weimer <fweimer at redhat dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>, OndÅej BÃlka <neleai at seznam dot cz>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 04 Nov 2013 09:43:08 +0100
- Subject: Re: [PATCH v2 1/2] Add nmalloc and nrealloc
- Authentication-results: sourceware.org; auth=none
- References: <20131031164614 dot GA28117 at domone dot podge> <20131031202932 dot 8942074699 at topped-with-meat dot com> <20131103165411 dot GA27987 at domone dot podge> <5276AB5B dot 8020208 at cs dot ucla dot edu>
On 11/03/2013 09:00 PM, Paul Eggert wrote:
I would avoid macros whose arguments are types; in this
case they're not worth the extra confusion caused by the fact that
they're not function-like. Just have the callers invoke nmalloc,
with no NMALLOC macro. It's easier and less error-prone to
read and write code like this:
new_global = nmalloc (new_nalloc, sizeof *new_global);
than code like this:
new_global = NMALLOC (new_nalloc, struct link_map *);
The downside is that
new_global = nmalloc (new_nalloc, sizeof new_global);
type-checks (and may even be correct on some architectures), but this
fails reliably at compile time:
new_global = NMALLOC (new_nalloc, struct link_map);
I understand the reservations about magic macros, though.
--
Florian Weimer / Red Hat Product Security Team