Re: bzr commit into mysql-6.0-semi-sync-1.0 tree (hezx:2635) WL#4398

[He Zhenxing]

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.

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

> 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