[Python-Dev] noreply@sourceforge.net: [Python-bugs-list] [Bug #111620] lots of use of send() without verifyi ng amount of data sent. (original) (raw)

Fredrik Lundh Fredrik Lundh" <effbot@telia.com
Sat, 12 Aug 2000 11:12:19 +0200

guido wrote:

> Indeed. I didn't actually check the story, since Guido was = apparently > convinced by its validity. =20 I wasn't convinced! I wrote "is this true?" in my message!!! =20 > I was just operating under the assumption that > send() did behave like write(). I won't blindly believe Guido = anymore ! :) =20 I bgelieve they do behave the same: in my mind, write() doesn't write fewer bytes than you tell it either! (Except maybe to a tty device when interrupted by a signal???)

SUSv2 again:

If a write() requests that more bytes be written than there
is room for (for example, the ulimit or the physical end of a
medium), only as many bytes as there is room for will be
written. For example, suppose there is space for 20 bytes
more in a file before reaching a limit. A write of 512 bytes
will return 20. The next write of a non-zero number of bytes
will give a failure return (except as noted below)  and the
implementation will generate a SIGXFSZ signal for the thread.=20

If write() is interrupted by a signal before it writes any data,
it will return -1 with errno set to [EINTR].=20

If write() is interrupted by a signal after it successfully writes
some data, it will return the number of bytes written.=20

sockets are an exception:

If fildes refers to a socket, write() is equivalent to send() with
no flags set.

fwiw, if "send" may send less than the full buffer in blocking mode on some platforms (despite what the specification implies), it's quite interesting that nobody has ever noticed before...