Sun, 17 Jul 88 20:01 EDT
We can put the Wollongong/recvfrom question to rest. I have what I need
to know concerning QIOs plus an understanding of the Crusades (see
1) The QIO interface DOES require the extra two bytes in the recvfrom
parameter. "The returned "sockaddr" structure is preceeded by
a 16-bit length. Here is the reasoning -- the networking code under VMS
uses "DIRECT-IO" which involves locking down pages. The QIO support for
this allows you lock down a primary buffer (the read/write buffer) and
one secondary buffer. The real UNIX way is to have 3 areas -- the
read/write buffer, the returned sockaddr and the returned length. But
this is exceedingly difficult to do with VAX/VMS QIOs." [David Kashtan].
2) The extra two bytes are not necessary if you go through the C library
and not the QIOs. As the Wollongong folks picked up, I was obviously
using the QIOs. The C library smooths out some rough edges and also gives
you a few more functions. [Jerry Scott].
The Ada interface I was using imported the QIOs directly instead of getting
to them via the C library; thus anything you would get for free via the
library (such as the two byte work around) was lost and was killing my code.
3) The real problem was that the documentation makes the QIOs look like
implement the socket interface (the spare two bytes are used in an example
MACRO program, but the normal sockaddr is used in the documentation.)
I have messages from Wollongong asking for more detail, so I can pursue
this off of tcp-ip.
4) Finally, it is no wonder there were Crusades if people then took
as seriously as we take programming languages today. My comment on being
able to read MACRO brought as much mail as the socket/QIO issue. MACRO, C,
and Ada all got praise and flames. The funny part is that my intention was
to emphasize that I had to read the code ITSELF and ignore the comments.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:42:51 GMT