Fitch@DOCKMASTER.ARPA (07/18/88)
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 comment 4). 1) The QIO interface DOES require the extra two bytes in the recvfrom from 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 they 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 religion 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. --Jack Fitch@Dockmaster.Arpa