From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13033 Path: news.gmane.org!.POSTED!not-for-mail From: Christopher Friedt Newsgroups: gmane.linux.lib.musl.general Subject: Re: getaddrinfo(3) / AI_ADDRCONFIG Date: Thu, 12 Jul 2018 22:53:12 -0400 Message-ID: References: <20180711003816.GV1392@brightrain.aerifal.cx> <20180711012640.GW1392@brightrain.aerifal.cx> <20180711164417.GX1392@brightrain.aerifal.cx> <20180711170034.GY1392@brightrain.aerifal.cx> <20180713014910.GC1392@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1531450292 5397 195.159.176.226 (13 Jul 2018 02:51:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 13 Jul 2018 02:51:32 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-13049-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jul 13 04:51:28 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fdoB6-0001JR-J8 for gllmg-musl@m.gmane.org; Fri, 13 Jul 2018 04:51:28 +0200 Original-Received: (qmail 1956 invoked by uid 550); 13 Jul 2018 02:53:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1938 invoked from network); 13 Jul 2018 02:53:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=T2Lsm82kTr4LDdCWi+7HpV1m6nie5uETvv1emaweov4=; b=bqQhQMLONFb+Jc6Ve/g+SlNGyLVC3AKLEXwT3PNss2UopN4NF+IMm6Mbv9XFLLmd5s JAiQVrnFaH4QcggcVT2+FLkEXMG6+nFkf4xnF9KDLb0MELhCo7dKm5IWk5JW+qoRcsZH xhTQeVONdUbTMukJYxDxQSHTOqtWM3P59n02FGfDY6sjgf+xfXy8LVvT3E7AZBaQZyb1 kCsmLRqDs8skCOqlLR5YaMNobPYuBY4argAkvyRibBuHPjOCZ6RcJq1A4WOPzMPqT7Zt 7WmkyctP19sOSsvzPYJ3eJ9hqiSNFetSN3iZZKofMB4SKnBoZFdFrLQ9smQexYKVhkXj IG4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=T2Lsm82kTr4LDdCWi+7HpV1m6nie5uETvv1emaweov4=; b=sjmQ6RESld4CbibxE6yHlt/Bap7y7ySgs1Sggc1Mi6WV3QtZfkV7lV+JZG8d0g7IHv mf6ktw7gTLBDq4UfuKu/wRzGiLI+eCca1yf2aqhRTpHmK2I3ovp7C8fc5ZLc0CPVvYOz 2O6xBIhGmy0EAHyG7VH+O67aKGbceiZanxyfXkXW67CogHyds2nCpNpYQvR7OW/wg3at EIBlTxVqpEV42VOAsWAj1z6J9uJW+Za5VT5JYu5WgUs0PbKZ/xe58qj0S3I9WeC46qQ0 zsV3PS1YT0jqz/AY5PWF5X9xgxF7zu3qyXy51A8s4+kR5MzI3CgoLeVb6h7w9Aq9kbNA smZQ== X-Gm-Message-State: AOUpUlFCelh6Ic7cbg9gTNqruKOSVyAgEu+7yp4BVQZfxkF2UY/VqRUS 1XkfpI3S1uRjMuRhvNLFbXQP+1cKDILQfPbnOYtYU7DU X-Google-Smtp-Source: AAOMgpdIqcHh+qpGKKSyU5ZNDLxkU41sqFcwCokj5mPAQbPYDM0E+8NNx1M+FH9s6mhc95LlT4nbz0lqo+DkkDa5U7k= X-Received: by 2002:aca:af15:: with SMTP id y21-v6mr5328969oie.324.1531450403795; Thu, 12 Jul 2018 19:53:23 -0700 (PDT) In-Reply-To: <20180713014910.GC1392@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13033 Archived-At: On Thu, Jul 12, 2018 at 9:49 PM Rich Felker 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