Issue 1166195: Using size_t where appropriate (original) (raw)

This patch is (a first draft of) an attempt to make Python properly use size_t where necessary. This work is triggered by compilation on Win64 (where the compiler warns about potential truncation errors a lot). The rationale for the patch is that size_t might be larger than int, in particular on 64-bit platforms, and that the size of a memory chunk cannot reliably be measured with an int.

It turns out that using size_t is not enough, since values can sometimes also be negative. For these cases, a "signed" size_t is used, which is called Py_ssize_t and is a define for ssize_t if the compiler supports the latter.

The guideline for converting int to size_t used in this patch is this:

• if the variable is meant to store the number of bytes, and is always guaranteed to be positive, and could get arbitrarily large, use size_t
• if the value could be negative also, use ssize_t
• if the value is meant to store a number of "things", but this directly translates into size_t (e.g. number of pointers, number of characters), also use size_t/ssize_t
• if the value is in a range limited to 32-bit int (e.g. the number of characters in a path name), convert the size_t to int, after asserting that the value really is in the range.

This version is work in progress, and needs review. I hope to work on it during the sprints at PyConDC.