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...
</F>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4