-----Original Message----- From: Michael Widenius [mailto:monty@askmonty.org] Sent: Donnerstag, 3. November 2011 11:29 To: Vladislav Vaintroub Cc: sje@cup.hp.com; maria-developers@lists.launchpad.net 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