>>>>> "MARK" == MARK CALLAGHAN <mdcallag@stripped> writes:
MARK> On Sat, Oct 17, 2009 at 10:55 AM, Ingo Strüwing
> <Ingo.Struewing@stripped> wrote:
>> Hi all,
>> the coding style changes, agreed upon by the MySQL Server coding style
>> government committee on 2009-06-26, is now part of the Coding Guidelines
>> in the internals manual:
MARK> I am glad these have been published. I have comments and questions
MARK> about bool and my_bool.
MARK> * Functions should return zero on success, and non-zero on error,
MARK> so you can do:
MARK> Can this be extended to state that these functions should return int
MARK> rather than bool/my_bool? Some functions today use bool/my_bool and
MARK> return TRUE on error. I have to read the code for these to figure out
MARK> whether TRUE is returned on error.
Functions that only returns 0 or 1 should be bool or my_bool.
Normally you should assume that <> 0 is an error.
MARK> bool exists only in C++. In C, you have to use my_bool (which is
MARK> char); it has different cast rules than bool:
MARK> int c= 256*2;
MARK> bool a= c; /* a gets 'true' */
MARK> my_bool b= c; /* b gets zero, i.e. 'false': BAD */
MARK> my_bool b= test(c); /* b gets 'true': GOOD */
MARK> Given the examples above, my_bool is completely broken, use of it will
MARK> introduce bugs and should be removed from the code. Is that scheduled
MARK> to be done?
I personally like my_bool, as it gives me information 'at a glance' if
a function only returns 0 or 1. As C doesn't have 'bool', we have to
resort to use my_bool. Storing anything else than 0 or 1 in a my_bool
is to regarded as bug in the cdoe that needs to be fixed.
Fortunately some newer compilers gives a warning when you assign an
int to a char and we will find errors like this in our build system
and get them fixed.