On 2003-09-21 at 07:21:46 [+0200], Tyler Dauwalder wrote: > Howdy folks, > > So I've been thinking: sometimes you have a function that returns a boolean > value, but might fail for whatever reason -- say it takes a filename > parameter, and you pass it a name for a file that doesn't exist. If you > leave the return value for the function as a bool, then you have to define > one of the truth assignments to really mean "either the given truth > assignment, or the function failed"; sometimes it's really hard to pick > which truth assignment to use, or you'd like to get an informative error > code out upon failure. > > Another option is then to use a boolean output parameter and return a > status_t instead, but output parameters are just annoying. > > So, I'm thinking that if we were to add the following definitions to > Errors.h: > > #define B_FALSE 0 > #define B_TRUE 1 > > then, one could just return a status_t for the function, check for "< B_OK" > to see if an error occurred (yielding a hopefully useful error code if so), > and if not, check against B_TRUE or B_FALSE to see what the result of the > function was. > > You could also define a bool_t or a boolstatus_t type that's identical to > status_t, but whose use as a return value would flag the function as > operating as described above instead of just returning a standard status_t. > > Thoughts? Doesn't sound too bad. bool_t would clash with the equally named RPC type. boolstatus_t would be OK with me, but others might find it a bit long -- in case that is so, maybe bstatus_t? CU, Ingo