mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: gilles@poolp.org, musl@lists.openwall.com
Subject: Re: freeaddrinfo() comments and questions
Date: Sat, 23 Nov 2019 12:48:36 -0500	[thread overview]
Message-ID: <20191123174836.GJ16318@brightrain.aerifal.cx> (raw)
In-Reply-To: <87lfs67d1b.fsf@mid.deneb.enyo.de>

On Sat, Nov 23, 2019 at 05:50:08PM +0100, Florian Weimer wrote:
> * gilles:
> 
> > November 23, 2019 5:05 PM, "Florian Weimer" <fw@deneb.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


      reply	other threads:[~2019-11-23 17:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-23 15:46 gilles
2019-11-23 16:05 ` Florian Weimer
2019-11-23 17:41   ` Rich Felker
2019-11-23 16:31 ` gilles
2019-11-23 16:50   ` Florian Weimer
2019-11-23 17:48     ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191123174836.GJ16318@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=fw@deneb.enyo.de \
    --cc=gilles@poolp.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).