Writing zero bytes to a socket

[WW304289]

x.c below gives 1 on VMS and 0 on Linux.

I realize that this is unspecified behavior: "If nbyte is zero and the file is not a regular file, the results are unspecified" and socket is not a regular file -- see Base Definitions.

Still, this particular behavior -- returning 1 as a number of written bytes when asked to write zero bytes -- makes no sense to me. Especially given the fact that read() function returns zero when asked to read zero bytes from a socket (the results are unspecified for both read() and write()).

Any comment from C RTL team?

Thanks,
-Boris

x.c
---
#include
#include
#include
#include
#include

int main()
{
int sock, rtn;
char bytes[1];
static struct sockaddr_in serv_addr;

errno = 0;
if ((sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) {
printf("socket() e:%d\n", errno);
return 0;
}

serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = htonl((127<<24|1));
serv_addr.sin_port = htons(23);

errno = 0;
if (connect(sock, (struct sockaddr*) &serv_addr, sizeof(serv_addr)) < 0) {
printf("connect() e:%d\n", errno);
return errno;
}

errno = 0;
rtn = write(sock, bytes, 0);
printf("write() rtn=%d errno=%d\n", rtn, errno);
}

$ cc/ver
HP C V7.3-018 on OpenVMS IA64 V8.3
$ run x.exe
write() rtn=1 errno=0
$

$ uname -rvm
2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64
$ a.out
write() rtn=0 errno=0
$

[Hoff]

As you undoubtedly well know, "Unspecified" means that the C RTL and TCP could choose to ship over a base64-encoded Hubble telescope image of the former-planet known as Pluto if they so choose, and there's no need to justify whatever happens.

But that the call returns 1 and 0 does look particularly bogus; I'd have expected -1 and EBORIS, :-), err, EINVAL here.

Probably worth lobbing a formal report, regardless.

[WW304289]

> Probably worth lobbing a formal report, regardless.

We'll see what C RTL folks have to say.

It looks like a regression, an unintended consequence of some change which slipped through CRTL regression test system. The TCP/IP stack should have nothing to do with the issue: for zero nbyte, the call should not have been forwarded to TCP/IP services at all. If this has changed, it may explain the problem.

For the reference: the underlying socket function for read() is recv() and for write() is send(). It is unspecified how recv() and send() process a zero-length message.

Thanks,
-Boris

[John Gillings]

Boris, (THE Boris? ;-)

>We'll see what C RTL folks have to say.

Are you expecting a response from them here? You might get lucky, but I wouldn't hold my breath. There are a few HP engineers who read and respond here, but it's definitely not an HP support channel. I'd recommend logging a formal report with your local customer support centre.

[P Muralidhar Kini]

Hi Boris,

>> Still, this particular behavior -- returning 1 as a number of written bytes when
>> asked to write zero bytes -- makes no sense to me.
Looks like problem handling boundary conditions (i.e. when requesting for zero
bytes).

>> We'll see what C RTL folks have to say.
Yes, this is not a official HP support channel. To get a response from the official
support channel, you need to forward this question to the local HP customer
support. This way the query would eventually find its way to the CRTL team.

Regards,
Murali

[Richard J Maher]

Hi Boris,

FWIW, (a bit of what Hein refers to regularly as "hand-waving") I would also say it's a bug.

The stuff I do explicitly ignores (doesn't forward on) zero-byte messages, which makes me believe they are perfectly valid with the $qio interface.

Cheers Richard Maher

[WW304289]

John Gillings wrote:
> Boris, (THE Boris? ;-)

Yes :-)

> Are you expecting a response from them here?

Yes, I still am :-)

> I'd recommend logging a formal report with your local customer support centre.

We may do it, as a courtesy to HP. We know how to work around the problem.

I still remember the days when treating formal and informal problem reports equally
was one of my objectives. The ultimate goal was quality of the product.

P Muralidhar Kini wrote:
> This way the query would eventually find its way to the CRTL team.

This is very encouraging :-)

But I appreciate your reply, I'm sure you want to help. I assume, you are not far from the current CRTL developers, or at least work for the same company. Can you alert them to this thread, please? If my assumption is wrong, I apologize.

Richard J Maher wrote:
> [...] I would also say it's a bug.

I'm sure it is a bug. I cannot believe they shipped Hubble to Pluto on purpose :-)

The send() function, which is the underlying virtual I/O function for write() when file descriptor is associated with a socket, returns zero for a zero-length message, so,
it must be something in write() itself. Besides, the execution should not even reach
send() when nbyte is zero. ("virtual I/O function" is not "virtual" in the C++ sense,
of course, this is what they used to be called in the CRTL land).

I also believe it is a regression because the observed behavior does not match listings, but our VMS Listings CD is a kind of old.

Thanks,
-Boris

[Hein van den Heuvel]

John Gillings wrote:
> Boris, (THE Boris? ;-)

Boris G. crtl-savvy Boris. Ah! Where did you end up?

John> Are you expecting a response from them here?
Boris>Yes, I still am :-)
Yes, the team is trying. Murali is there often. Other contribute.


Boris> I still remember the days when treating formal and informal problem reports equally
was one of my objectives. The ultimate goal was quality of the product.

And that was a very laudable goal.
From my limited perspective the COBOL folks did GREAT in this space. Each report was appreciated and just labeled according to origin. Internal-notes, comp.os.vms, Wallstreet-journal, whatever.
The C-rtl probably did great as well, I just paid less attention there.

Murali> This way the query would eventually find its way to the CRTL team.
Boris> This is very encouraging :-)

Well, you know, it is at least on par or possible better than the classic OpenVMS tean. Some there were rather anal about process. A bug was not a bug until properly reported. :-(.

>> I also believe it is a regression because the observed behavior does not match listings, but our VMS Listings CD is a kind of old.

Running just 8.3, not 8.3H1 ?
Can you try under H1?
Supposedly the OpenVMS team is working on an easy access test system similar to the old testdrive some time sone.

( I might know how to get you 8.3H1 Crtl listings. Send Email. )

Cheers,
Hein van den Heuvel ( at gmail dot com )

[P Muralidhar Kini]

Hi Boris,

>> But I appreciate your reply, I'm sure you want to help. I assume, you are
>> not far from the current CRTL developers, or at least work for the same
>> company. Can you alert them to this thread, please? If my assumption is
>> wrong, I apologize.
Good guess. Smart indeed.
Yes, I will talk to the CRTL team and forward this query to them.
I am not sure how loaded they are currently with other work items and cannot
guarantee a response but will try my best to get their opinion on this.


>> I still remember the days when treating formal and informal problem reports
>> equally was one of my objectives. The ultimate goal was quality of the
>> product.
Thats right. Same with me.
I am interested mainly on XFC (VMS data cache) and to some extent on XQP
(VMS metadata cache) as well. I do monitor discussions on XFC and XQP very
closely. Any suggestions or problems in these areas i do make a note of it
for performance improvement and/or fixing.

Every bug has its day. So better fix it when you know about it cause if you
dont fix it then someday the bug will eventually make its way through the
official path!.

Hein,
>> Yes, the team is trying. Murali is there often. Other contribute.
Right. I do read various questions posted here and try to help as much as
possible. Not only that, reading various solutions/suggestions in this forum
is very interesting/informative indeed. Thanks to all the experts around.

Regards,
Murali

[Murali C]

Hi Boris,

Thnaks for finding this. Write returning one byte as written; when asked to write zero bytes is a bug in CRTL. We will add this to our internal list of items to be worked on. If you need an immediate fix, please log a formal report through HP customer support.

Thanks,
OpenVMS CRTL Engineering