He Zhenxing wrote:
> On 2008-06-10 Tue 10:08 +0200, Mats Kindahl wrote:
>> He Zhenxing wrote:
>>> Hi
>>>
>>> Agreed, then what's you opinion on using types such as uint32,
>>> uchar,my_bool, etc. Should we use these types in plugin.h, or more
>>> generally, should we use these types in the interfaces, or should we
>>> just use int, long, char, bool instead.
>> Personally, I don't see the need for uchar, which just saves typing, nor
>> for my_bool, since it is just an int. OTOH, types like uint32 et.al.
>> does server a purpose. If you have a look at stdint.h (a standard
>> function), there are some inspiration to what should be there (these are
>> also standard types, so it might be a good idea to actually use those
>> names for the SDK).
>>
>> I don't think it is a good idea to use int, long, short, and long long
>> (with some exceptions), because they have different sizes on different
>> platforms. Here's a list of what I think we need (what names we use for
>> the non-fundamental types is not that important):
>>
>> int8_t
>> int16_t
>> int32_t
>> int64_t
>> uint8_t
>> uint16_t
>> uint32_t
>> uint64_t
>
> I think in structures, we should use these types in stead of int, long,
> etc, so that they can be binary compatible between platforms. But I am
> not quite sure if we should use these in function arguments or not.
> Maybe this depends on how the argument is used. Anyway I think these
> types are needed for the SDK.
I agree that we should use it for structures, but I think we need it for
the parameters to functions as well. The reason is that it is possible
that the parameters are passed on the stack, which then means that it
will be aligned and stuffed much in the same way as fields in a
structure is aligned and stuffed.
The exceptions are some of the "natural" types for the machine, for
example "int", "size_t", "char", and "void*", which cannot vary and
still have a conforming implementation. Those items will probably be
passed and stored in the same way independent of the compiler. Note that
"size_t" is a typedef that often is "unsigned long", but can in reality
be defined as other types, that's why I'm saying that "size_t" will stay
pretty much the same independent of compiler, even though it might have
different types in different compilers.
The only way to know absolutely for sure it to test it.
>> char (to denote a character, not an integer)
>> unsigned char (to denote a byte)
>> void*
>> size_t
>> int (for error codes and boolean values)
>>
>
> No problem with this.
Good.
>
>> Something like that. The fewer types we use, the better.
>>
>> /Matz
>>
>>> On 2008-06-09 Mon 09:54 +0200, Sergei Golubchik wrote:
>>>> Hi!
>>>>
>>>> On Jun 09, Mats Kindahl wrote:
>>>>> He Zhenxing wrote:
>>>>>> Hi Mats
>>>>>>
>>>>>> Did you noticed that I included <my_global.h> in plugin.h?
>
>>>>>>
>>>>>> The functions I added in plugin.h used some typedefs defined in
> it,
>>>>>> such as uint32, uchar. I am not quite sure other stuffs defined
> in
>>>>>> my_global.h should be exported or not.
>>>>> No, actually I didn't. I'm reluctant to include my_global.h since it
>>>>> contain a lot of dependencies on other code in the server... wait...
>>>>>
>>>>> ... no, I don't think it is a fundamental problem to include the
> file.
>>>>> There are a lot of definitions that are not really needed, but I see
>>>>> no harm in including it from plugin.h, we just have to make sure
> that
>>>>> it is part of the SDK as well.
>>>> No, please, don't inclue my_global.h in plugin.h, my_global.h is
>>>> internal, we are changing it freely and want to continue doing that.
>>>> plugin.h will be VERY soon strictly monitored to make it difficult for
>>>> anybody to modify it, the less files are public the better.
>>>> Besides, my_global.h is and always was written as internal - meaning
>>>> nobody tried to avoid namespace conflicts when it's used with other
>>>> projects' headers, nobody tried to minimize the dependencies, or
>>>> definitions/declarations in it, etc. It cannot be made a part of the
>>>> public API as is.
>>>>
>>>> And it'd be best if your plugin would not need it, if at all possible.
>>>> (for all plugins I've helped to create it's true, they don't need
>>>> internal headers)
>>>>
>>>> Regards / Mit vielen Grüssen,
>>>> Sergei
>>>>
>>
>> --
>> MySQL Code Commits Mailing List
>> For list archives: http://lists.mysql.com/commits
>> To unsubscribe: http://lists.mysql.com/commits?unsub=1
>
--
Mats Kindahl
Lead Software Developer
Replication Team
MySQL AB, www.mysql.com
