← Back to team overview

maria-developers team mailing list archive

Re: Handling size_t -> int conversions

 

Hi!

>>>>> "Bo" == Bo Thorsen <bo@xxxxxxxxxxxx> writes:

Bo> I'm working on getting rid of the compiler warnings on 64 bit Windows.
Bo> There are literally thousands of places, where we store a size_t in an 
Bo> int, and the compiler warns about possible loss of data.

Bo> I'm trying to figure out how to handle this in the best way, and I need 
Bo> a bit of advice on how to proceed.

Bo> First, is it acceptable to change all/most of these vars from int to 
Bo> size_t? In places where there is a local variable that stores the 
Bo> difference between two pointers, it's fine. But what about places like 
Bo> struct z_stream_s in zlib.h?

We should over time fix all these warnings, but we have to do so that
we can still relatively easly do merges.

In other words, we should do the least amount of changes that fixes
most of the code.  This means that we should probably first
concentrate on fixing structs then mysys and strings library and only
then other cases.

All cases of between pointers to different objects should be fixed
(these are potential bugs)

As one can't have have strings > 4G in MySQL it's not critical that we
fix all size_t issues as these can't cause any bugs. However getting
rid of warnings is always a good thing as having many warnings will
cause people to miss the important warnings.

We should probably not fix this in zlib.h as we may want to be binary
compatible with the normal zlib library.

Bo> How do you guys prefer to see patches on this - one big patch, or 
Bo> several smaller patches?

One patch per module would be preferably.

Regards,
Monty



References