classification
Title: setobject.c warnings under 64-bit Windows
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.1, Python 3.2, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: loewis, pitrou, rhettinger
Priority: low Keywords:

Created on 2010-08-15 17:33 by pitrou, last changed 2010-08-17 20:01 by pitrou. This issue is now closed.

Messages (7)
msg113976 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-08-15 17:33
None of these warnings look critical (one affects the "search finger" optimization of pop(), one affects the result from __length_hint__ on set iterators, and the other the hash value of frozensets without any obviously bad consequences), but you might want to take a look at them anyway.

(for the record, a C "long" is 32-bit under 64-bit Windows, so a Py_ssize_t won't fit in it)

1>..\Objects\setobject.c(743) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'long', possible loss of data
1>..\Objects\setobject.c(772) : warning C4244: '*=' : conversion from 'Py_ssize_t' to 'long', possible loss of data
1>..\Objects\setobject.c(819) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'long', possible loss of data
msg113984 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-08-15 18:11
For the length hint, it would be best to use PyLong_FromSize_t, as in dictobject.c. It would be sad if __length_hint__ would return a much-too-small value (or even a negative number).

For the search finger, dictobject has opted to make me_hash of type Py_ssize_t.
msg113996 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-08-15 18:55
Antoine, thanks for posting these.
msg114001 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-08-15 19:24
There is also a similar warning for deque iterators' __length_hint__ (line 1124 in _collectionsmodule.c).
msg114151 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-08-17 19:40
This is now fixed in r84146 (py3k) and r84151 (3.1). I've made the "hash" field a Py_ssize_t, consistently with the dict implementation.
msg114152 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-08-17 19:46
I'm not sure whether backporting it to 3.1 is a good idea. It's potentially an ABI change (although a minor one, as the field offsets remain the same, only the interpretation of the padding may change).
msg114155 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-08-17 20:01
> I'm not sure whether backporting it to 3.1 is a good idea. It's
> potentially an ABI change (although a minor one, as the field offsets
> remain the same, only the interpretation of the padding may change).

Well, it is unlikely that anyone is accessing setentry structures
directly, given that no API function returns one, and the hash collision
resolution algorithm is not provided.
History
Date User Action Args
2010-08-17 20:01:08pitrousetmessages: + msg114155
2010-08-17 19:46:36loewissetmessages: + msg114152
2010-08-17 19:40:50pitrousetstatus: open -> closed
resolution: fixed
messages: + msg114151
2010-08-15 19:24:50pitrousetmessages: + msg114001
2010-08-15 18:55:26rhettingersetmessages: + msg113996
2010-08-15 18:11:07loewissetnosy: + loewis
messages: + msg113984
2010-08-15 17:33:35pitroucreate