[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF4BF-RPKSYir55e7Z7V8NdPd16Sq+VD3g3O0ybcb++ccM4MUQ@mail.gmail.com>
Date: Thu, 12 Jul 2018 22:53:12 -0400
From: Christopher Friedt <chrisfriedt@...il.com>
To: musl@...ts.openwall.com
Subject: Re: getaddrinfo(3) / AI_ADDRCONFIG
On Thu, Jul 12, 2018 at 9:49 PM Rich Felker <dalias@...c.org> wrote:
> Something's not going right with our communication about this. I've
> attached an untested patch that's closer to what I've been looking
> for. It corrects an oversight I'd made, that we need to block
> cancellation during the probe, and localizes the change as originally
> requested. Please let me know if it works. Arguably it might be nicer
> to replace the repeated code with a table and 2-iteration for loop.
I originally wrote my patch with the intention of being as unobtrusive
as possible but rather than disagree realized it was better to just do
what you wanted me to.
The struct was a better solution for when the addrconfig logic lived
in a separate function. It probably could have even been a separate
static function inside of getaddrinfo.c, but I anticipated that you
would not have liked that.
Definitely correct to disable pthread cancellation.
I used struct sockaddr_storage to avoid declaring more than one
sockaddr because I thought you would have preferred that. Personally,
I would have preferred to use two separate sockaddr too. Solves that
problem.
Originally, I wanted to use a loop over the length of a table, but
figured you would dislike that in favour of readability. Assuming
there will only be ever be AF_INET and AF_INET6 support for
getaddrinfo(3), handling it this or that way is fine.
The patch works for me as is or with the loop.
C
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.
