On Sun, 2010-11-07, Stefan Fuhrmann wrote:
[...]
> Thanks all for the replies. Here is how I see it plus
> a couple of things I discovered in the meantime.
>
> * general consensus: overlapping definitions with
> inconsistent meaning are bad.
> * enums are always compatible with ints, so we can't
> make them incompatible at compile time
We can't make *enums* incompatible, but we could make the tristate a
different type, such as a struct or a pointer, which would be
incompatible. That can be option (3). But it doesn't seem to be
necessary, as your option (2) seems to provide good enough separation.
> That leaves us with two basic options.
>
> (1) Define that a tristate is a "nullable" boolean (.net speak).
> To me, this seems to be the way that it is being used
> right now. However, one might be tempted to (miss-)use
> tristates instead of booleans "just in case". That would
> be bad.
>
> (2) Define that tristates and booleans are similar but
> fundamentally different. Using values >1 for tristate
> values would make them "always true" in boolean
> expressions. So, the logic would probably fail early
> and the compiler might even generate a warning.
>
> I think there is no big risk associated with neither
> of these options. If people feel uncomfortable with (1),
> I'm happy to switch to (2).
That would be OK for me.
> But I also discovered two issues with the current boolean
> type definitions. First, TRUE and FALSE are defined
> after I use them in svn_tristate_t which can be fixed easily
> and leads directly to the second issue.
>
> We only define TRUE and FALSE in case they have
> not been defined, yet. Since we rely on their numerical
> values, we should at test for these values in case the
> macros are pre-defined (#error if not).
That's over-kill. Not necessary.
> If people agree, I will implement (2) and the fix the other
> two issues.
- Julian
Received on 2010-11-08 12:58:48 CET