[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191123174836.GJ16318@brightrain.aerifal.cx>
Date: Sat, 23 Nov 2019 12:48:36 -0500
From: Rich Felker <dalias@...c.org>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: gilles@...lp.org, musl@...ts.openwall.com
Subject: Re: freeaddrinfo() comments and questions
On Sat, Nov 23, 2019 at 05:50:08PM +0100, Florian Weimer wrote:
> * gilles:
>
> > November 23, 2019 5:05 PM, "Florian Weimer" <fw@...eb.enyo.de> wrote:
> >
> >> * gilles:
> >>
> >>> In these other implementations, it is possible to write a custom
> >>> struct addrinfo allocator and use freeaddrinfo() on it, just like it
> >>> is possible to use getaddrinfo() and use a custom release function on
> >>> it. This is not a very common use-case, granted, but it is one
> >>> nonetheless, and one that works and has worked in a portable way for a
> >>> long time across a wide variety of systems.
> >>
> >> I think this is clearly undefined. There is no way to know how
> >> storage for ai_addr and ai_canonname is managed. These pointers could
> >> point to separate allocations, made with malloc. They could be
> >> interior pointers to the same top-level allocation at which start the
> >> struct addrinfo object is allocated. Nothing even needs to use
> >> malloc, including the outer struct addrinfo object.
> >
> > Fair enough for this use-case, I think you are right and it works by accident.
> >
> > What is your opinion on the other comments ?
>
> The most obvious interpretation is that callers can tweak the ai_next
> member before calling freeaddrinfo, and that freeaddrinfo performs the
> usual iteration over this single-linked list, freeing each list
> element individually.
>
> In general, relying on this does not seem particularly useful to me.
> Applications should probably call freeaddrinfo only on the pointer
> provided by getaddrinfo, and refrain from writing to any struct
> members.
The strictest interpretation is that you can't modify the list at all,
and call freeaddrinfo only on the original (entire) list or some tail
of it. However I think the spec is ambiguous and it's worth supporting
the case where the list has been split by nulling an ai_next pointer.
Perhaps removing segments by updating ai_next to point to some later
tail of the list is also intended to be ok. Anything beyond that seems
pretty dubious to me.
To me, the intended use of this functionality seems to be that you
might want to remove unwanted entries from the returned list, without
having to make your own container structure to store the ones you want
to keep. Freeing parts of it is not useful to save memory; rather, the
idea of freeing parts is that, if the implementation itself can't
reach the list members you remove, it would have no way to free them
later when you free the list. Thus it's expected that you notify the
implementation you're removing them by calling freeaddrinfo on
sublists.
Unfortunately all of this is underspecified.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
