writev() on a SOCK_STREAM socket

[kid joe]

Hi,

Do I need to retry writev() on a blocking Unix-domain SOCK_STREAM socket,
or will it always write out the exact number of bytes I asked for?

For example:

if (write(fd, (const char *) presp, resp_size) != resp_size)
{
warn("Writing %lu bytes failed\n", resp_size);
return;
}

this seems to work, but I want to know if it's "really OK" in terms of
ANSI Standards etc.

[pete]

Re: writev() on a SOCK_STREAM socket

kid joe wrote:

Hi,
>
Do I need to retry writev() on a blocking Unix-domain SOCK_STREAM socket,
or will it always write out the exact number of bytes I asked for?
>
For example:
>
if (write(fd, (const char *) presp, resp_size) != resp_size)
{
warn("Writing %lu bytes failed\n", resp_size);
return;
}
>
this seems to work, but I want to know if it's "really OK" in terms of
ANSI Standards etc.

The ANSI C standards have nothing to do with
write(), writev(), Unix, and sockets.

--
pete

[Jens Thoms Toerring]

Re: writev() on a SOCK_STREAM socket

kid joe <spamtrap@spamt rap.invalidwrot e:

Do I need to retry writev() on a blocking Unix-domain SOCK_STREAM socket,
or will it always write out the exact number of bytes I asked for?

For example:

if (write(fd, (const char *) presp, resp_size) != resp_size)
{
warn("Writing %lu bytes failed\n", resp_size);
return;
}

this seems to work, but I want to know if it's "really OK" in terms of
ANSI Standards etc.

The C standard won't tell you anything about this problem since
there's not even a write() function (or an open() function to
start with;-) defined there. But even if you ask in e.g. the
comp.unix.progr ammmer group you will have to tell how exactly
you did open the file (descriptor). If you e.g. did open it in
non-blocking mode then for sure write() may return before even
a single byte was written. Results may also depend on signals
being blocked etc. - the POSIX standard is what you need to refer
to in this case.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\______________ ____________ http://toerring.de

[Flash Gordon]

Re: writev() on a SOCK_STREAM socket

pete wrote, On 20/06/08 00:01:

kid joe wrote:

>Do I need to retry writev() on a blocking Unix-domain SOCK_STREAM socket,
>or will it always write out the exact number of bytes I asked for?

<snip>

>this seems to work, but I want to know if it's "really OK" in terms of
>ANSI Standards etc.

>
The ANSI C standards have nothing to do with
write(), writev(), Unix, and sockets.

As this appears to be about Uni like systems comp.unix.progr ammer would
be a good place to ask. I suspect the answer is "no" but I could easily
be wrong.
--
Flash Gordon

[rahul]

Re: writev() on a SOCK_STREAM socket

On Jun 20, 3:50 am, kid joe <spamt...@spamt rap.invalidwrot e:

Hi,
>
Do I need to retry writev() on a blocking Unix-domain SOCK_STREAM socket,
or will it always write out the exact number of bytes I asked for?
>
For example:
>
if (write(fd, (const char *) presp, resp_size) != resp_size)
{
warn("Writing %lu bytes failed\n", resp_size);
return;
}
>
this seems to work, but I want to know if it's "really OK" in terms of
ANSI Standards etc.

This topic is not about ANSI but POSIX standards.
<off-topic>
You asked about writev and you are using write. Nevertheless, the same
errors are defined for both. write can fail in various cases: EPIPE(if
pipe is broken), EINT(if interrupted by a signal) and EAGAIN ( if fd
opened as O_NONBLOCK and the call would block). There are a few more
error scenarios which the man pages document. Its always a good idea
to consult the man pages(or any equivalent documentation).
</off-topic>

[CBFalconer]

Re: writev() on a SOCK_STREAM socket

rahul wrote:

>

.... snip ...

>
This topic is not about ANSI but POSIX standards.
<off-topic>
You asked about writev and you are using write. Nevertheless, the
same errors are defined for both. write can fail in various cases:
EPIPE (if pipe is broken), EINT (if interrupted by a signal) and
EAGAIN ( if fd opened as O_NONBLOCK and the call would block).
There are a few more error scenarios which the man pages document.
Its always a good idea to consult the man pages(or any equivalent
documentation). </off-topic>

Most here prefer that you only refer the enquirer to a suitable
newsgroup, rather than attempt to answer off-topic questions. The
reason is that the people to criticize your answer just don't exist
here, so faulty answers won't get exposed. And we all make
mistakes.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.


** Posted from http://www.teranews.com **

[Antoninus Twink]

Re: writev() on a SOCK_STREAM socket

On 20 Jun 2008 at 7:19, CBFalconer wrote:

rahul wrote:

>write can fail in various cases:

[snip good answer]

>There are a few more error scenarios which the man pages document.
>Its always a good idea to consult the man pages(or any equivalent
>documentation) .

>
Most here prefer that you only refer the enquirer to a suitable
newsgroup, rather than attempt to answer off-topic questions.

s/Most/A vocal minority/

The reason is that the people to criticize your answer just don't
exist here, so faulty answers won't get exposed.

This is materially false: the intersection between posters to clc and
posters to cup is large, and might well be larger still if it wasn't for
the topicality zealots stifling POSIX discussions here.

In any case, the answer is a precis of formal documentation (the write
manpage), so it's very unlikely to be "faulty".

And we all make mistakes.

Yes - some more than others.

[vippstar@gmail.com]

Re: writev() on a SOCK_STREAM socket

On Jun 20, 10:19 am, CBFalconer <cbfalco...@yah oo.comwrote:

rahul wrote:
>
... snip ...
>

This topic is not about ANSI but POSIX standards.
<off-topic>
You asked about writev and you are using write. Nevertheless, the
same errors are defined for both. write can fail in various cases:
EPIPE (if pipe is broken), EINT (if interrupted by a signal) and
EAGAIN ( if fd opened as O_NONBLOCK and the call would block).
There are a few more error scenarios which the man pages document.
Its always a good idea to consult the man pages(or any equivalent
documentation). </off-topic>

>
Most here prefer that you only refer the enquirer to a suitable
newsgroup, rather than attempt to answer off-topic questions. The
reason is that the people to criticize your answer just don't exist
here, so faulty answers won't get exposed. And we all make
mistakes.

Agreed. I posted a follow-up to comp.unix.progr ammer only, advicing
rahul that, along with correcting his reply (and answering OP).
I hope the discussion continues there...