On Tue, Oct 20, 2009 at 4:25 PM, Michael Widenius <monty@stripped> wrote:
>>>>>> "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?
>>> 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
Are you against any change to the coding guideline unless it is
enforced immediately for all code?
Existing code already has a mix of conventions for this, including:
1) return type int
2) return type my_bool and use TRUE for error, FALSE for success
3) return type my_bool and use 1 for error, 0 for success
I want 2) and 3) to gradually be replaced by 1)
> 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.
Use #define or typedef so that my_bool is implemented by _Bool.