maria-developers team mailing list archive

[Michael Widenius <monty@xxxxxxxxxxxx>]

Hi!

>>>>> "Vladislav" == Vladislav Vaintroub <wlad@xxxxxxxxxxxxxxxx> 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