List:Internals« Previous MessageNext Message »
From:MARK CALLAGHAN Date:October 21 2009 12:03am
Subject:Re: Coding style changes of 2009-06-26 now in the guidelines
View as plain text  
On Tue, Oct 20, 2009 at 4:25 PM, Michael Widenius <monty@stripped> wrote:
>
> 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

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.

-- 
Mark Callaghan
mdcallag@stripped
Thread
Coding style changes of 2009-06-26 now in the guidelinesIngo Strüwing17 Oct
  • Re: Coding style changes of 2009-06-26 now in the guidelinesMARK CALLAGHAN17 Oct
    • Re: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius18 Oct
      • Re: Coding style changes of 2009-06-26 now in the guidelinesMARK CALLAGHAN18 Oct
        • Re: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius18 Oct
          • Re: Coding style changes of 2009-06-26 now in the guidelinesJay Pipes18 Oct
          • Re: Coding style changes of 2009-06-26 now in the guidelinesMARK CALLAGHAN18 Oct
            • Re: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius19 Oct
    • Re: Coding style changes of 2009-06-26 now in the guidelinesIngo Strüwing19 Oct
      • Re: Coding style changes of 2009-06-26 now in the guidelinesMats Kindahl19 Oct
        • RE: Coding style changes of 2009-06-26 now in the guidelinesVladislav Vaintroub19 Oct
          • Re: Coding style changes of 2009-06-26 now in the guidelinesMats Kindahl19 Oct
            • RE: Coding style changes of 2009-06-26 now in the guidelinesVladislav Vaintroub19 Oct
            • Re: Coding style changes of 2009-06-26 now in the guidelinesRoy Lyseng19 Oct
          • RE: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius21 Oct
      • Re: Coding style changes of 2009-06-26 now in the guidelinesMARK CALLAGHAN19 Oct
        • Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Ingo Strüwing19 Oct
          • re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Michael Widenius21 Oct
            • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Ingo Strüwing21 Oct
              • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Michael Widenius21 Oct
                • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in the guidelines]MARK CALLAGHAN21 Oct
                  • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in the guidelines]Michael Widenius21 Oct
                  • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Konstantin Osipov23 Oct
                    • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Jay Pipes23 Oct
                • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Ingo Strüwing22 Oct
                  • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Michael Widenius22 Oct
                    • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Ingo Strüwing22 Oct
                      • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in theguidelines]Michael Widenius23 Oct
                    • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in the guidelines]MARK CALLAGHAN23 Oct
                      • Re: Style proposal [Re: Coding style changes of 2009-06-26 now in the guidelines]Michael Widenius24 Oct
        • Re: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius21 Oct
          • Re: Coding style changes of 2009-06-26 now in the guidelinesMARK CALLAGHAN21 Oct
            • Re: Coding style changes of 2009-06-26 now in the guidelinesMichael Widenius21 Oct