maria-developers team mailing list archive
Mailing list archive
Re: Bug in ENUM options handling?
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
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.
>> -----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?
>> Vladislav> Hi,
>> Vladislav> I would prefer not to use ulong at all. It is not uniformly
> bit on 64
>> Vladislav> OSes. If one needs unsigned integer that 64 bit on 64 bit
>> 32 or 32
>> Vladislav> bit, size_t seems to be the right choice to me, at least I
> have not
>> 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?
> 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
> 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
> server with 5GB buffer size took half an hour on a 4G machine (huge
> in the debug version of malloc in C runtime), and to catch the error I
> had to run 1 hour test.
> So potential data loss in truncation it is not only an annoying warning,
> may well be a bug that results in data corruption on the user's site.
> 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