[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN 1.3.0-rc4 ...for NetWare... builds

From: Max Bowsher <maxb1_at_ukf.net>
Date: 2005-11-27 11:54:46 CET

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

NormW wrote:
> Greetings All,
> Just trying a build of the 1.3-rc4 taeball for SVN for the NetWare box
> and two 'issues' arise:
>
> 1. Some sources use 'SVN_NEON_0_25' but my compiler says:
>
> #if SVN_NEON_0_25
>
> is an incomplete statement, _unles_ I define iy as '1', which is not
> what the comments in svn_private_conig.h.in suggest. Perhaps that should
> be:
>
> #ifdef SVN_NEON_0_25
>
> or change the the comments relating to the setting perhaps?

That's strange.

I thought that C compilers were supposed to treat undefined macros as
zero. I've always assumed that the reason autoconf macros usually are
either 1 or undefined, is so you can safely test them with either #if or
#ifdef, and get the same result.

If the NetWare compiler is acting differently, then that's kind of
annoying, but at least is is easy to fix in this case.

> 2. The latest Novell C library indicates inet_addr() returns a structure
> (in_addr_t) and the compiler doesn't like:
>
> #define INADDR_NONE ((in_addr_t) -1)
>
> Trying to find out from Novell how to test for -1 but wondering if there
> is any other way of writting this to get the same result when testing
> laddr against INADDR_NONE later in the program (ne_socket.c).

Remember that neon is a separate project with its own mailing list.

Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFDiZB2fFNSmcDyxYARAleCAKCMx9y4DJTnqeSYAxcVD/hu05fU9gCeI4Lp
nuE7PXHMcmt2vMfEfGGZLeY=
=Y7pS
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 27 11:55:42 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.