Re: svn commit: r602176 - /apr/apr/trunk/network_io/unix/sockaddr.c

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Joe Orton wrote:
> On Tue, Dec 11, 2007 at 02:35:36PM -0600, William Rowe wrote:
>> 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.
> 
> I'd guess the original API was designed simply to produce some 
> "human-readable" representation of the address, i.e. for logging 
> purposes; it's not an unreasonable interface to provide per se.  Perhaps 
> changing it in 2.0 to add a flags argument to make the ::ffff:-stripping 
> optional would make sense.
> 
> (and also maybe exposing inet_pton and inet_ntop interfaces using 
> apr_sockaddr_t)

Well I'm back to this, we've had requests to address this in 1.3.0, and now
I'm trying to do something dirt simple stupid...

   apr_sockaddr_t *client
    -> char* text
      -> domain pipe to a root process
        -> validate against legit patterns
          -> create low-port origin sockaddr_t from text
            -> domain pipe back to the requestor

Grrr.

Bill