From dev-return-19615-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Tue Dec 11 20:36:14 2007 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 49844 invoked from network); 11 Dec 2007 20:36:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Dec 2007 20:36:14 -0000 Received: (qmail 59949 invoked by uid 500); 11 Dec 2007 20:36:02 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 59898 invoked by uid 500); 11 Dec 2007 20:36:01 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 59887 invoked by uid 99); 11 Dec 2007 20:36:01 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Dec 2007 12:36:01 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [64.202.165.37] (HELO smtpauth13.prod.mesa1.secureserver.net) (64.202.165.37) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 11 Dec 2007 20:35:39 +0000 Received: (qmail 6530 invoked from network); 11 Dec 2007 20:35:38 -0000 Received: from unknown (67.162.45.134) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 11 Dec 2007 20:35:37 -0000 Message-ID: <475EF498.8080606@rowe-clan.net> Date: Tue, 11 Dec 2007 14:35:36 -0600 From: "William A. Rowe, Jr." User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: dev@apr.apache.org Subject: Re: svn commit: r602176 - /apr/apr/trunk/network_io/unix/sockaddr.c References: <475D8C0E.7020800@rowe-clan.net> <20071210195547.GA23734@infiltrator.gizzard.com> <20071210203411.GA28175@redhat.com> <475DAD92.4020204@rowe-clan.net> <20071210215841.GA29536@redhat.com> <475DBE68.7080808@rowe-clan.net> <20071211101115.GA5642@redhat.com> <475E729F.4040904@rowe-clan.net> <20071211155557.GA19709@redhat.com> <475EDDFF.2070101@rowe-clan.net> <20071211192704.GA29167@redhat.com> In-Reply-To: <20071211192704.GA29167@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Joe Orton wrote: > On Tue, Dec 11, 2007 at 12:59:11PM -0600, William Rowe wrote: >> Joe Orton wrote: >>> No. But given that new interfaces are needed can we just give up on >>> hacking the resolver and fix the actual issue, i.e. allow duplication of >>> the sockaddr object? >> We disagree that this isn't an issue in and of itself, but I'll tweak to >> the 'new flag' as you suggest (and it could affect a broader range of cases >> than just family==APR_INET6). > > Blargh. What problems will be solved by introducing these changes? > None. Is it actually a good idea for APR to encourage propagation of > v4-mapped IPv6 addresses? No. How many checkins will it take to > introduce this feature correctly? As yet unknown. How much has this > new code actually been tested? I'll guess "not at all"... Contrawise, the initial patch was tested, as I believed I needed it for mod_ftp, and it resolved the flaw. The revised patch was "minimally" tested, because immediately after authoring it, I jumped on solving mod_ftp from the sa-copy method. > network_io/unix/sockaddr.c: In function 'find_addresses': > network_io/unix/sockaddr.c:424: warning: unused variable 'error' Trivial to fix. That's not the real origin of your objection. It worked as we simply called call_resolver twice with the same args. Stupid but not lethal. > How much more time should we waste introducing changes which add > complexity, bring potential regressions, and solve non-problems? I vote > none and revert sockaddr.c back to before r602176. If you want this resolved, we agree this needs to be reverted in apr 2.0? http://svn.apache.org/viewvc/apr/apr/trunk/network_io/unix/sa_common.c?view=log&pathrev=63986#rev60946 talk about ancient history, but most of the time we butt heads there's a root in a bad design decision. If this decision was right, then apr should have some reciprocal behavior to get from point A to B and back again. Apparently internal consistency doesn't interest you? I consider it essential, even if the user has to throw a flag to get out of the mess we created. Presuming this is a vote to not provide this feature and not a technical veto, let's let others chime in a while. Happy to fix that flaw. As Jeff authored the ::ffff: unmapping, I'm especially interested in his input. >>> Something like this? >> We don't disagree this is also a useful feature (which I hacked into ftp >> just last night). I don't care for _clone, though. _dup makes more sense >> to me, but since it will take an existing *sa, I'm ok with _copy too. >> See the end of the message for all apr examples of those three forms. > > Fair enough. I've a vague preference for _copy over _dup since the > former is not an abbreviation, so I'll go with that unless anybody else > pipes up. +1 - fyi that call to vars_set is overkill, only addr->ipaddr_ptr needs to be adjusted once the entire sa has been pmemdup'ed (out of all of the adjustments within vars_set). Bill