maria-developers team mailing list archive

["Jakob Lorberblatt" <jakob@xxxxxxxxxxxxxxxxxxxxxxx>]

I believe the the debate ongoing below can be laid to rest at *MOST*
platforms size_t will work correctly, I have found few exceptions, such as
GCC prior to 2.4 size_t is defined as a signed integer, in sys/types.h to
match the definitions located in this file for other nix related
platforms, and stddef.h just includes this definition; this is a very old
version of GCC and I believe (correct me if I am wrong) it would not
compile MariaDB's source code anyway, not positive though haven't tried
it.
     Also I found an interesting side-note, with a separate but obscure
hardware related issue with this variable size; on m68k apparently
size_t is defined as a 16bit unsigned int, when the processor is
capable of handling objects larger as arguments to memcpy (cited in
an eetimes.com article), not a very likely situation to run into but
the macro SIZE_MAX if it exists for all MariaDB supported platforms
may provide the method for evaluating its signed-ness.
   I am of the understanding that yes, size_t should be unsigned and
ssize_t would be the signed version if needed for something.

Jakob Lorberblatt
>
>
>> -----Original Message-----
>> From: Michael Widenius [mailto:monty@xxxxxxxxxxxx]
>> Sent: Donnerstag, 3. November 2011 11:29
>> To: Vladislav Vaintroub
>> Cc: sje@xxxxxxxxxx; maria-developers@xxxxxxxxxxxxxxxxxxx
>> Subject: Re: [Maria-developers] Bug in ENUM options handling?
>
> <skip>
>
>> Vladislav> Hi,
>> Vladislav> I would prefer not to use ulong at all. It is not uniformly
>> 64
> bit on 64
>> bit
>> Vladislav> OSes. If one needs unsigned integer that 64 bit on 64 bit
>> OSes,
> and
>> 32 or 32
>> Vladislav> bit, size_t  seems to be the right choice to me, at least I
> have not
>> seen
>> Vladislav> exceptions from this rule (but though someone mentioned that
>> on Cray that
>> Vladislav> would not work:). uintptr_t  sounds ok too.
>
> Hi Monty
>
>> size_t is not a good choice as it's signed on some platforms.
>> uintptr_t is not a good thing either, as it has to do with pointers,
>> not integer handling (will look strange in function prototypes).
>
> Can you tell me on which platforms that we support  it is signed?
> Wikipedia
> says it is unsigned http://en.wikipedia.org/wiki/Size_t , and personally I
> do not recall seeing anything else (I do not exclude any possibility it
> was
> so on some historical systems, but I'm interested in current ones we use)
>
>> 'ulong' stands in MariaDB for 'the most efficient integer type that is
>> may be longer than uint.  I don't think it's a problem to use ulong as
>> long as you don't mix it with uint / ulonglong without casting.
>>
>> That said, as this is fixed in 5.5 and there is no known problem with
>> MariaDB 5.3 related to this, this shouldn't be a big issue.
>
> There *may* be plenty of latent hidden problems with it. This bug
> http://bugs.mysql.com/bug.php?id=43932  took me a week to debug . MyISAM
> used to do arithmetic on ulongs that resulted in the index corruption once
> key buffer size was larger than 4GB on Windows (ulong multiplication). i.e
> it took me a week to debug this problem, just because the startup of a
> debug
> server with 5GB buffer size took half an hour on a 4G machine (huge
> memsets
> in the debug version of malloc in C runtime), and to catch the error I
> also
> had to run 1 hour test.
>
> So potential data loss in truncation  it is not only an annoying warning,
> it
> may well be  a bug that results in data corruption on the user's site.
>
> Wlad
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~maria-developers
> Post to     : maria-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-developers
> More help   : https://help.launchpad.net/ListHelp
>