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?


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).


View raw message