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
