Anton Tyurin added the comment:
The same error in the use of socket.send(). Is it possible to use size_t for
len instead of int?
According to http://www.python.org/dev/peps/pep-0353/ Py_ssize_t on x86 is
typedef for int, and size_t has the same size.
On x64 sizeof size_t is 8bit, that covers
Anton Tyurin added the comment:
typo fix
8bite -> 8 bytes
--
___
Python tracker
<http://bugs.python.org/issue18100>
___
___
Python-bugs-list mailing list
Un
Anton Tyurin added the comment:
This issue is similar like http://bugs.python.org/issue9566.
It seems reasonable to apply a similar fix.
But why not use the types described in the signature functions in
. In particular use for len size_t, and for n - ssize_t
Anton Tyurin added the comment:
There seems to be no, because there's this bug is already fixed in Python 3,
according to
http://hg.python.org/cpython/file/c1a400501db6/Modules/socketmodule.c#l3290.
But the use of Py_ssize_t (len and n) hides the potential type conve
Anton Tyurin added the comment:
I could be wrong, but:
ssize_t
send(int socket, const void *buffer, size_t length, int flags);
so length is size_t, but Py_ssize_t is ssize_t (signed to unsigned).
PS. sorry for my bad English
--
___
Python tracker
Anton Tyurin added the comment:
According to man send:
only sendmsg() if input length argument overflows a ssize_t on OS X. But
truncating extradata in sendall() without exception is bad idea, because
sendall() never returns count of successfully sent bytes. So we'll never know
