Bert Huijben wrote: > > -----Original Message----- > > From: Stefan Fuhrmann [mailto:stefanfuhrm...@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
