On Wed, 16 Mar 2005, Dan Fandrich wrote:

> The new test 237 is showing some problems on Tru64. Tru64 V5.1 resolves
> 1218.91.256.127 as 194.91.0.127 (i.e.
> (1218&0xff).(91&0xff).(256&0xff).(127&0xff)) and therefore a different error
> code than normal systems because it actually tries to connect to that bogus
> address. It seems to be a bug in Tru64's inet_addr() function. On a related
> note, my man page for inet_addr(3) says that inet_addr is deprecated and
> inet_aton(3) should be used instead. That's probably not going to help
> here, though.

I've just committed code that uses inet_pton() instead in lib/hostip4.c. It
might make a difference. If it doesn't, I'm considering allowing the test
suite to accept errorcode "Z or Y" instead of just a single error code as
today.

I find ANDing each number part with 255 a hilariously weird thing to do...

> Netware builds are performed differently now. Compare for example
> http://curl.haxx.se/auto/log.cgi?id=20050316142805-22023
> with yesterday's version:
> http://curl.haxx.se/auto/log.cgi?id=20050315142555-20292
> It appears that the "target=netware" parameter is being ignored in the
> testbuild.pl script.

Yes, I believe my changes to testcurl.pl broke the Netware builds. But all I
did was attempting to treat 'targetos' as TARGET only, and not necessarily
build os as well.

I'd of course appreciate of one of the Netware guys could check it out and see
if they have a good idea on a fix.

> It would be nice to disable valgrind when using testcurl.pl. This patch
> will do it by allowing you to add a option like
> --maketestopts="TEST_F='\$(TEST) -a -p -n\'" when running testcurl.

I think I would prefer it to work like this:

         --runtestsopts="-a -p -n"

... basically simply passing in the options (using make) to use with the
runtests.pl script.

-- 
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
       Dedicated custom curl help for hire: http://haxx.se/curl.html