apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: svn commit: r602176 - /apr/apr/trunk/network_io/unix/sockaddr.c
Date Tue, 11 Dec 2007 19:27:04 GMT
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"...

network_io/unix/sockaddr.c: In function 'find_addresses':
network_io/unix/sockaddr.c:424: warning: unused variable 'error'

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.

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


View raw message