This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients
Date 2005-03-18.19:59:12
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
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.
History
Date User Action Args
2007-08-23 15:42:15adminlinkissue1166195 messages
2007-08-23 15:42:15admincreate