Hi,

Thanks for the great work on Neon! I use it pretty much every day as part
of Subversion. However I encountered one tiny problem in Neon:

Neon 0.24.7 (bundled into SVN) was failing to do any name lookups
successfully when compiled by a 64-bit GCC running on HPUX 11.11 on HPPA.
I think it would exhibit this problem on other LP64 systems too. The
following patch fixes it for me:

diff -Naur neon-0.24.7/src/ne_socket.orig.c neon-0.24.7/src/ne_socket.c
--- neon-0.24.7/src/ne_socket.orig.c    2005-07-01 16:18:39.000000000
-0400
+++ neon-0.24.7/src/ne_socket.c 2005-08-16 04:33:59.000000000 -0400
@@ -670,7 +670,7 @@
 #endif
     }
 #else /* Use gethostbyname() */
-    unsigned long laddr;
+    in_addr_t laddr;
     struct hostent *hp;

     laddr = inet_addr(hostname);

Ie, the assumption that unsigned long is 32 bits wide does not hold in an
LP64 environment (by definition).

A quick poll of some UNIX boxes shows that this 'in_addr_t' type is used
for the return type of 'inet_addr' under Linux, Tru64 and HPUX, but not
under SCO OpenServer or (surprisingly to me) under Solaris 7, which use
'unsigned long'. So I suppose it needs an extra autoconf test?

Solaris 7 runs on 64-bit SPARC chips, so I don't understand how this works
on that OS. Is it going to return a 64-bit long with the inet addr in the
low 32 bits? Ugh. I haven't investigated this but I can if useful.

Alternatively, you could use preprocessor conditionals on the values of
limits.h::UINT_MAX and friends to define a 'ne_u32' type at compile time,
thus avoiding an extra autoconf test.

Please, at the very worst, use an 'unsigned int' variable plus a cast, not
'unsigned long' - that would fix 64-bit compiles but break 16-bit
compiles, which in the year 2005 is a good tradeoff, I think.

Hope this helps, and thanks again for Neon,

--matt

Matthew Sanderson
Senior Programmer (UNIX)
TCG Information Systems Pty Ltd
Sydney, Australia
[EMAIL PROTECTED]
http://www.formtrap.com/
+61 (02) 8303 2407
_______________________________________________
neon mailing list
[email protected]
http://mailman.webdav.org/mailman/listinfo/neon

Reply via email to