Julian Foad <julianfoad@btopenworld.com> writes:
> >>By the way, the fact that the r15051 conditional compilation guards
> >>use "#if" not "#ifdef" should be okay: any macro name remaining
> >>after expansion is replaced with 0L by the preprocessor, so if
> >>SVN_NEON_0_25_0 isn't defined at all, then all those conditionals
> >>should simply evaluate to false.
> > See also K&R p. 232.
>
> That's all true, but I consider it bad practice to make use of this
> fallback behaviour in circumstances where the definition of the
> variable is under our control and is therefore known to be of either
> the defined/undefined kind or the 1/0 kind at our option. Setting the
> variable according to one scheme and testing it according to the other
> scheme causes unnecessary confusion for humans, and makes the
> associated compiler warnings (where available) useless for detecting
> real bugs because they have to be turned off or ignored.
>
> Well, that's my three-penn'orth.
Really, the inconsistency starts in svn_private_config.h, where the
toggling is between this
/* Is FOO support enabled? */
/* #undef SVN_HAVE_ZLIB */
and this
/* Is FOO support enabled? */
#define FOO 1
But as for the tests in the code, I actually prefer to use "#if",
because that way it means what you want it to mean even if someone
sticks "#define FOO 0" into a header somewhere.
In other words, "#if FOO" Does The Right Thing both when FOO is not
defined at all, and when it is defined to be 0. (I suspect this is
why the preprocess has this behavior in the first place.)
Of course, then the tests for the opposite sense should probably look
like this
#if ! SVN_NEON_0_25_0
instead of this
#ifndef SVN_NEON_0_25_0
the latter being what I actually committed. I admit to inconsistency
there :-). But if we're going to change something, it should be that,
not the "#if"s.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 14 22:34:23 2005