![](https://secure.gravatar.com/avatar/83f7132335c546a6c3ca3aedb8d9dba3.jpg?s=120&d=mm&r=g)
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@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
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp