Bert Huijben wrote:
> > -----Original Message-----
> > From: Stefan Fuhrmann [mailto:stefanfuhrmann_at_alice-dsl.de]
> > after stumbling twice over this issue, I ran grep
> > and found that the current usage of svn_tristate_t
> > does not depend on the actual numerical values
> > used for its states.
> >
> > Therefore, I propose to define svn_tristate_false
> > equal to FALSE and svn_tristate_true equal to
> > TRUE. That way, we can compare booleans with
> > tristates and assign booleans to tristates. Without
> > that, we need to write code like
> >
> > if ((get_some_bool() ? svn_tristate_true : svn_tristate_false) ==
> > get_a_tristate())
> > ...
> >
> > Also, the following will compile without warning but
> > requires the patch to do what was intended:
> >
> > // FALSE becomes "unknown", TRUE becomes "false"
> > svn_tristate_t my_tristate = get_some_bool();
>
> What do you try to get as result here?
>
> I'm not 100% sure if tests like (12 == 12) really always return the defined
> value TRUE
(I'm just addressing the C language facts in this response.)
In C, when an operator such as "==" is defined to yield a Boolean value,
it *always* return 0 for "false" or 1 for "true", never other values for
"true".
However, non-Boolean-valued expressions, such as "flags & 0x40", can be
used where a Boolean value is wanted, such as "if (flags & 0x40)" or
"override || (flags & 0x40)". Any non-zero is regarded as "true".
> and we most likely have other functions that return just some !=
> 0 value as svn_boolean_t.
Yes: there can be functions in our code or in libraries that we call
that return other values than 1 to mean "true", although we tend to
avoid doing so in our own code.
> And what if TRUE happens to be defined as -1?
It never will be. It's defined as 1 specifically so that it matches the
C language definition of "true".
> (In that case unknown and FALSE would have the same value)
- Julian
Received on 2010-11-04 12:12:13 CET