maria-developers team mailing list archive
Mailing list archive
Re: Bug in ENUM options handling?
> -----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 64
bit on 64
> Vladislav> OSes. If one needs unsigned integer that 64 bit on 64 bit OSes,
> 32 or 32
> Vladislav> bit, size_t seems to be the right choice to me, at least I
> Vladislav> exceptions from this rule (but though someone mentioned that
> on Cray that
> Vladislav> would not work:). uintptr_t sounds ok too.
> 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.