Hi!
>>>>> "MARK" == MARK CALLAGHAN <mdcallag@stripped> writes:
MARK> On Mon, Oct 19, 2009 at 12:01 AM, Ingo Strüwing
> <Ingo.Struewing@stripped> wrote:
>> Hi Mark,
>>
>> MARK CALLAGHAN, 17.10.2009 20:31:
>>
>> ...
>>> * Functions should return zero on success, and non-zero
> on error,
>>> so you can do:
>>>
>>> Can this be extended to state that these functions should return int
>>> rather than bool/my_bool? Some functions today use bool/my_bool and
>>> return TRUE on error. I have to read the code for these to figure out
>>> whether TRUE is returned on error.
>>
>> thanks for the suggestion. Is this a formal request to the MySQL Server
>> coding style government committee?
>>
>>
> http://forge.mysql.com/wiki/MySQL_Internals_Coding_Guidelines#How_we_maintain_the_server_coding_guidelines
>>
>> In this case, please add, what the implementation strategy should be:
>> Change all existing code, or let only new code follow the proposal.
MARK> I don't expect existing code to be changed. But it would be nice for
MARK> people to slowly fix things when they edit code. My requests are:
MARK> 1) Use Unix style for functions (return type is int, 0 == success).
MARK> The current rule doesn't mention the return type. Do not use
MARK> bool/my_bool for this with FALSE==errror and TRUE==success in place of
MARK> 1.
Having a mix of convention in the same code will just cause conflicts
and is something that should be strongly discouraged
MARK> 2) Use _Bool for my_bool on platforms that support C99
Having both _Bool and my_bool would make the code less portable.
Better to stick with with my_bool as we are already using it all over
the places.
MARK> 3) Do not use the literals 0 and 1 in place of FALSE and TRUE
Matter of style, but don't object to it (as long as no one uses this
as an argument that FALSE should mean error).
Regards,
Monty
