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
