[Python-Dev] Proper usage of size_t

Tim Peters tim.one at comcast.net
Thu Sep 4 22:37:17 EDT 2003


[Martin von Loewis]
> On Win64, the Windows SDK compiler gives tons of warnings
> that type conversions may involve truncation. For example,
> in 2.3 stringobject.c, a subset of the warnings is
>
> ..\Objects\stringobject.c(285) : warning C4267: '=' : conversion
> from 'size_t' to 'int', possible loss of data
> ..\Objects\stringobject.c(316) : warning C4244: 'function' :
> conversion from '__int64' to 'int', possible loss of data
> ..\Objects\stringobject.c(554) : warning C4244: 'function' :
> conversion from '__int64' to 'int', possible loss of data
> ..\Objects\stringobject.c(812) : warning C4267: 'function' :
> conversion from 'size_t' to 'int', possible loss of data
> ..\Objects\stringobject.c(2154) : warning C4244: 'function' :
> conversion from '__int64' to 'int', possible loss of data
> ..\Objects\stringobject.c(3410) : warning C4267: 'return' :
> conversion from 'size_t' to 'int', possible loss of data
> ..\Objects\stringobject.c(3618) : warning C4267: 'return' :
> conversion from 'size_t' to 'int', possible loss of data
> ..\Objects\stringobject.c(3737) : warning C4244: '=' : conversion
> from '__int64' to 'int', possible loss of data
> ..\Objects\stringobject.c(4072) : warning C4244: '=' : conversion
> from '__int64' to 'int', possible loss of data
> ..\Objects\stringobject.c(4076) : warning C4244: '=' : conversion
> from '__int64' to 'int', possible loss of data
>
> These warnings occur for stuff like
>
>   i = strlen(p);
>
> where i is of type int, but strlen returns size_t, and that might
> exceed what int can store. Likewise, in
>
>   _PyString_Resize(&string, s - PyString_AS_STRING(string));
>
> the pointer difference is of type size_t, but PyString_Resize
> expects int.
>
> I'd be willing to go through and replace "int" by "size_t"
> whereever I find it appropriate, for Python 2.4.

I've done that often in the past, but piecemeal.  Note that another raft of
changes usually follows from this:  it's not only the size of the integral
type that may change, but regardless of platform it's also a change from a
signed type to an unsigned type.  That often triggers a new round of
warnings (e.g., MSVC6 warns when mixing signed and unsigned in comparisons).

> I would keep the current object layout for the moment, but change
> function signatures, which would cause ABI breakage on platforms where
> sizeof(size_t)!=sizeof(int).
>
> What do you think?

It's overdue -- go for it!  +1.




More information about the Python-Dev mailing list