When using socket.sendall() to send a buffer of 2GB or more (for example, numpy.zeros(2*GB, dtype=numpy.uint8) ), it doesn't send anything at all.

In socketmodule.c, socket.sendall() sock_sendall uses an int for len, while this should be a Py_ssize_t.

"int len = pbuf.len;"
Why doesn't gcc emit a warning here?

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 the limits of reasonable use.

typo fix
8bite -> 8 bytes

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 <sys/socket.h>. In particular use for len size_t, and for n - ssize_t?

Does it affect Python 3, too?

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 conversion.

> But the use of Py_ssize_t (len and n) hides the potential type conversion.

Which type conversion?

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

> ssize_t send(int socket, const void *buffer, size_t length, int flags);

Oh, I didn't notice that. I hope that the result always fit in a ssize_t. If it is not the case, it is probably a bug in the kernel. An example of such bug:
http://xorl.wordpress.com/2009/04/10/cve-2009-1265-linux-kernel-rosex25netrom-integer-overflows/

On Solaris, read(), send() and probably other functions return EINVAL if input length argument overflows a ssize_t. We may be extra-safe by truncating the length to PY_SSIZE_T_MAX. But I would appreciate a test on Linux and Solaris with such huge values. Which kind of socket should be used to test such buffer?

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 about incomplete data transmition.

Is it good idea to test such buffer on Unix socket, for example?

Looks like this was fixed in 3.1 and 3.2 by r84150.

The issue is fixed in Python 3 by commit f72006f4429975a9d221e046e43dabd4f41eda23