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: [PATCH v2 1/2] Add nmalloc and nrealloc


On Mon, Nov 04, 2013 at 03:01:30PM -0500, Rich Felker wrote:
> On Mon, Nov 04, 2013 at 09:43:08AM +0100, Florian Weimer wrote:
> > 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.
> 
> What's worse still, if the macro takes a type and passes it to sizeof,
> a caller might inadvertently pass sizeof(type) itself, causing the
> macro to evaluate sizeof(sizeof(type)), i.e. sizeof(size_t), instead
> of the desired size.
>
This is not problem as it would be expanded to

((sizeof (type) *)  nmalloc (x, sizeof (sizeof (type))))


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