The current implementation of inet_ntop() on Win32 is failing unit testing. 

Background:  Winsock2 does not have inet_ntop() or inet_pton() functions. 
It does have more-or-less equivalent functions named WSAAddressToString()
and WSAStringToAddress(), but we are not currently using those.  Instead, we
use the fallback/generic code which currently does a simpleminded sprintf. 
This is causing unit testing to fail because the unit test expects the
canonical IPv6 textual representation from inet_ntop().

The generic inet_ntop() function needs to be fixed anyway and I'll be
sending that diff out shortly.  But now seems a good time to address the
question of native vs. generic methods:

Should we use the native methods mentioned above for Win32?

  + Easy to implement.

  - Generic functions would no longer be actively maintained.

  - Requires Winsock DLL to be loaded (client) for address manipulation.

Additionally, if we are going to continue using the generic methods for
Win32, should we also use them for Unix?  This would make the code
consistent across platforms, which is a double-edged sword: if the generic
code is correct, it's correct everywhere, but if it's buggy, it's also buggy
everywhere.

Note that I already have a fix for the generic inet_ntop() and code to use
the native methods on Win32.  Both the native and generic code for all
server platforms (Linux, Solaris 8, Win32) passes unit testing with my
changes.

-- 
The only thing more costly than stretching the schedule of an established
project is accelerating it, which is itself the most costly action known to
man.
        -- Norman Augustine
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.helixcommunity.org/pipermail/helix-server-dev/attachments/20041202/d42dce38/attachment.bin