> On Feb 18, 2019, at 12:59 PM, Steve Dickson <SteveD@xxxxxxxxxx> wrote:
>
>
> On 2/18/19 12:00 PM, Chuck Lever wrote:
>>> I also took a look at how freeaddrinfo(3) in glibc works:
>>>
>>> void
>>> freeaddrinfo (struct addrinfo *ai)
>>> {
>>> struct addrinfo *p;
>>>
>>> while (ai != NULL)
>>> {
>>> p = ai;
>>> ai = ai->ai_next;
>>> free (p->ai_canonname);
>>> free (p);
>>> }
>>> }
>>> It makes the assumption that ai_canonname is
>>> free-able memory....
>> Right, I seem to recall looking at this implementation when
>> I wrote the IPv6 support for nfs-utils. That seems sensible
>> to me.
>>
>> However Peter's point is not all C libraries have to work
>> that way, and I can see that argument too.
> I agreed....
>>
>> I have no objection to taking his fix as long as the hunk
>> in host_numeric_addrinfo() is dropped while we figure out
>> a more complete fix for that issue.
> Taking it out I can see us getting flagged for possible memory leaking....
Exactly, with glibc C, that memory will leak if it's not freed
there.
We need a different solution here that works with all C libraries.
If Peter agrees, I'll volunteer to have a look at this.
> Taking a look to why those frees were add... see commit 94ce1eb9
> They should look very familiar to you ;-)
>
>> I would also like to
>> see his fix use a helper like nfs_freeaddrinfo(), but that
>> is only a suggestion.
> That is a good suggestion... It definitely cleans up the code.
>
> steved.
>>
>>
--
Chuck Lever
