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 11:21:03 GMT
Joe Orton wrote:
> On Mon, Dec 10, 2007 at 04:32:08PM -0600, William Rowe wrote:
>> Joe Orton wrote:
>>> The previous behaviour makes far more sense, and it would not be 
>>> unreasonable for applications to rely on it.  In fact it looks like the 
>>> APR_IPV6_ADDR_OK flag is exactly a case which relies on that behaviour, 
>>> and is now presumably broken.
>> Interesting.  So, if we modify this to honor only the case of
>> APR_IPV4_ADDR_OK plus the APR_INET6 family, it would satisfy you?
> Not really, it violates the existing interface constraints:
> "APR_IPV4_ADDR_OK ... only valid if family is APR_UNSPEC"

Meaning - it is not defined (invalid) in 1.2.x.  I'll agree then, this
can't change in 1.2.x, and backporting becomes out of the question.

The remaining question is, when we say something is "only valid when..."
and therefore nobody has coded to this ever, granting an 'invalid'
combination with a new meaning seems legitimate.  No?

> I'd rather just see a new flag added alongside the existing 
> APR_IPV4_ADDR_* flags to make it explicit that this is a new and very 
> different interface guarantee, APR_IPV6_ADDR_V4MAPPED maybe.

Perhaps, but the flag existed and had no definition, so this really
strikes me as a rational solution.  My 2c.

Either the existing flag or a new flag, it doesn't seem like this can
be resolved before 1.3.0.  Does anyone see a way to make the reciprocal
sa-from-ip-and-inet6-family actually work before then?

I'm out of clues.


View raw message