From: Mats Kindahl
Date: September 8 2010 12:54pm
Subject: Re: [STYLE] use true/false in C++, not TRUE/FALSE
List-Archive: http://lists.mysql.com/internals/38069
Message-Id: <4C878789.1060601@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 09/08/2010 02:42 PM, Vladislav Vaintroub wrote:
>> -----Original Message-----
>> From: Mats Kindahl [mailto:mats.kindahl@stripped]
>> Sent: Wednesday, September 08, 2010 2:23 PM
>> To: internals@stripped
>> Subject: Re: [STYLE] use true/false in C++, not TRUE/FALSE
>>     
> <skip>
>   
>>>>         
>>> naah, I think we want sizeof(my_bool) == 1
>>>       
>> Why?
>>     
> To save 7/8 of a CPU register (joking  :) )
>
> Actually, I like what Davi proposed, sticking to int in the return code .  -1 for error and 0 for success was used for several
> decades on Unixes, and nobody came to complain about it expanded the error code space. 
> I'm also ok with changing conventions to have BOOL type, and functions that return return TRUE(==1) on success and FALSE(==0) on
> error , like that is used by convention on Windows, but I'm afraid I'll be alone here :) At least that convention is intuitive (TRUE
> on success is simple to understand, while FALSE on success is obscurity)
>
>   

I don't mind switching to using the same style everywhere and find the
idiom for Unix system calls OK, but for those cases that a boolean is
required (which is the issue at hand), I think switching to using "int"
for the typedef instead of "char" will avoid a lot of problems in
conversions.

Note: the use of -1 for error is because many system calls return
positive numbers on success (not necessarily 0), so it is just a way to
piggyback information in the return code. Typical examples are open(2),
which return a file descriptor or -1; write(2), which return number of
bytes written or -1; and select(2), which return the number of file
descriptors that have data available or -1.

So, from that perspective, I think that 0 for success, and a positive
number for error is just as fine, since in most cases, the MySQL
functions do not piggyback information in this manner (they are usually
passed back through output parameters instead). It would also avoid us
having to change gobs of code.

Just my few cents,
Mats Kindahl