List:Internals« Previous MessageNext Message »
From:Roy Lyseng Date:October 19 2009 2:20pm
Subject:Re: Coding style changes of 2009-06-26 now in the guidelines
View as plain text  

Mats Kindahl wrote:
> 
> Vladislav Vaintroub wrote:
>>> -----Original Message-----
>>> From: Mats.Kindahl@stripped [mailto:Mats.Kindahl@stripped] On Behalf Of
>>> Mats Kindahl
>>> Sent: Monday, October 19, 2009 1:47 PM
>>> To: Ingo Strüwing
>>> Cc: MARK CALLAGHAN; MySQL Internal
>>> Subject: Re: Coding style changes of 2009-06-26 now in the guidelines
>>>
>>>
>>>
>>> Ingo Strüwing 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_ma
>>> intain_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.
>>> If Mark does not submit it, I do.
>> As for me, I can get along with following conventions and with the mix of
>> them:
>> 1) Unix OS conventions (function returns int , success is 0, error  is -1,
>> error details in errno)
>> 2) Windows OS conventions (function returns BOOL, success is TRUE, error is
>> FALSE,  error details in GetLastError())
>>
>> I cannot get along with a convention "function returns my_bool, success is
>> TRUE, error is FALSE", it looks weird to me, violating the 2)
> 
> Yes, I also think that it is strange to have the "error convention" with a
> return value of my_bool.
> 
> I would prefer to have it as you suggest in the first alternative with the
> exception that I would like to have 0 as "No Error" and anything else as an
> error code. This is how it works in the code now, and the errno approach have
> proven to be problematic for multi-threaded code, so I would like to avoid that
> as far as possible.

You still need to pass other values such as operating system specific error 
information, parameters, etc, so I am happy with just signalling error as 
TRUE/FALSE, and passing the actual error information elsewhere. That information 
could be passed in a separate error object, or inside a thread-unique object 
(like the THD).

The choice of returning error as TRUE/1 and success as FALSE/0 is probably so 
spread throughout the code that it is impossible to change.

Thanks,
Roy
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