Hi!
"Vladislav" == Vladislav Vaintroub <wlad@montyprogram.com> writes:
<cut>
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).
Vladislav> Can you tell me on which platforms that we support it is signed? Wikipedia Vladislav> says it is unsigned http://en.wikipedia.org/wiki/Size_t , and personally I Vladislav> do not recall seeing anything else (I do not exclude any possibility it was Vladislav> so on some historical systems, but I'm interested in current ones we use)
From and older GCC doc:
---------------------- There is a potential problem with the size_t type and versions of GCC prior to release 2.4. ANSI C requires that size_t always be an unsigned type. For compatibility with existing systems' header files, GCC defines size_t in stddef.h to be whatever type the system's sys/types.h defines it to be. Most Unix systems that define size_t in sys/types.h, define it to be a signed type. Some code in the library depends on size_t being an unsigned type, and will not work correctly if it is signed ---------------------- As MariaDB may need to be ported to older systems, it's good to at least keep the above in mind.
'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.
Vladislav> There *may* be plenty of latent hidden problems with it. This bug Vladislav> http://bugs.mysql.com/bug.php?id=43932 took me a week to debug . MyISAM Vladislav> used to do arithmetic on ulongs that resulted in the index corruption once Vladislav> key buffer size was larger than 4GB on Windows (ulong multiplication). i.e Vladislav> it took me a week to debug this problem, just because the startup of a debug Vladislav> server with 5GB buffer size took half an hour on a 4G machine (huge memsets Vladislav> in the debug version of malloc in C runtime), and to catch the error I also Vladislav> had to run 1 hour test. The above may also happen on 32 bit systems. Yes, it's clear that things 'that may be big' should never by ulong. However, there are still cases when using int, uint and ulong make sence. I don't think it's a good idea to start to use ulonglong for everything, which would have been required to solve the above issue. Vladislav> So potential data loss in truncation it is not only an annoying warning, it Vladislav> may well be a bug that results in data corruption on the user's site. Regards, Monty