bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposed new module careadlinkat (renamed from breadlinkat)


From: Ben Pfaff
Subject: Re: proposed new module careadlinkat (renamed from breadlinkat)
Date: Fri, 01 Apr 2011 11:38:31 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

That's all carefully reasoned.  Thank you.  I only have one
remaining comment.

Paul Eggert <address@hidden> writes:

> On 04/01/2011 09:35 AM, Ben Pfaff wrote:
>> I would have guessed that there would be a global instance of
>> this allocator, something like:
>>
>> struct allocator standard_allocator = { malloc, realloc, free, NULL };
>
> I tried that at first, but it was more awkward for the common case
> where the standard functions are being used, because users of
> careadlinkat had to say "&standard_allocator" and they had to
> #include <allocator.h>.  Under the proposal they just say "NULL" and
> don't need to include <allocator.h>.  It's a minor point and I could
> easily be persuaded to switch back.

It's not important to me, at least.

Another choice would be to continue to accept NULL and just add
something like:

  if (!alloc)
    alloc = &standard_allocator;

or (probably with better choice of variable names):

  struct allocator *real_alloc = alloc ? alloc : &standard_allocator;

to the functions that use it.  Whether this is an improvement, in
my opinion at least, would depend on whether there are going to
be many functions that use this allocator interface.  If there
aren't, I can't see that it matters much either way.  If there
are, then it's not going to be nice to have

  void *(*pmalloc) (size_t) = malloc;
  void *(*prealloc) (void *, size_t) = realloc;
  void (*pfree) (void *) = free;
  void (*pdie) (void) = NULL;
  if (alloc)
    {
      pmalloc = alloc->malloc;
      prealloc = alloc->realloc;
      pfree = alloc->free;
      pdie = alloc->die;
    }

cut-and-pasted into each one of them.  Too much code duplication,
in my opinion.
-- 
Ben Pfaff 
http://benpfaff.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]