[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 23 Nov 2019 17:50:08 +0100
From: Florian Weimer <fw@...eb.enyo.de>
To: gilles@...lp.org
Cc: musl@...ts.openwall.com
Subject: Re: freeaddrinfo() comments and questions
* 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.
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.
