List:Internals« Previous MessageNext Message »
From:Michael Widenius Date:October 18 2009 9:16pm
Subject:Re: Coding style changes of 2009-06-26 now in the guidelines
View as plain text  
Hi!

>>>>> "MARK" == MARK CALLAGHAN <mdcallag@stripped> writes:

<cut>

>> Functions that only returns 0 or 1 should be bool or my_bool.

MARK> I am being pedantic, but functions that return TRUE or FALSE can be
MARK> bool/my_bool. A lot of MySQL source uses 0/1 in place of FALSE/TRUE
MARK> for bool/my_bool which makes the code harder to read.

MARK> I am not against using bool, I am against using it to return TRUE on
MARK> error. The libc model is for functions to return type int with 0 on
MARK> success and not 0 on error. I want the same to be done in MySQL.
MARK> Predicate functions (has_a(), is_a()) can return type bool.

In MySQL we are using relatively consistently 1 for errors.
Changing it now, would not be practical.

I personally prefer to have 1 for error, at is allows you, when the
needed arrises, to change the function to instead return error numbers
with very little code changes.

This is a question more about style and what you are used to.

Even in normal libraries, there are more and more functions that
returns error number in case of error (as it makes threaded programs
faster).

>> Normally you should assume that <> 0 is an error.

MARK> I want a higher standard than this as 'normally' allows for too many
MARK> exceptions. I don't want to remember those exceptions.

In MySQL code it's an exception that error is 0.

<cut>

>> 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.

MARK> I prefer to use a datatype that doesn't have this problem -- where
MARK> (my_bool) 256 == 0, (my_bool) 257 == 1.

MARK> New versions of gcc print a warning for this when -Wconversion is
MARK> used, older versions support -Wconversion but don't warn for this. But
MARK> MySQL doesn't even use -Wall, much less -Wconversion and there are 301
MARK> distinct warnings for -Wconversion from code in the sql directory with
MARK> MySQL 5.1.38.

We plan to shortly remove all of these in MariaDB and start using
-Wconversion and move to use -Wall ASAP.

Regards,
Monty
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