apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r602176 - /apr/apr/trunk/network_io/unix/sockaddr.c
Date Tue, 11 Dec 2007 20:35:36 GMT
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.  </shrug>  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

Mime
View raw message