fouts@AMES-NAS.arpa (08/06/86)
I've just heard the amusing (?) rumor that AT&T is about to change the
SVR2 validation procedure so that systems with Socket() functionallity will
fail, even if they are otherwise in complete compliance.
Anybody know anything about this one?
(Please respond to fouts@ames-nas, as I don't normally read these
lists.)
Thanks,
Martyron@BRL.ARPA (Ron Natalie) (08/07/86)
Well, one point is that fstat doesn't work right on systems that use sockets to support the PIPE system call. -Ron
guy@sun.uucp (Guy Harris) (08/09/86)
From the original article: > I've just heard the amusing (?) rumor that AT&T is about to change the > SVR2 validation procedure so that systems with Socket() functionallity will > fail, even if they are otherwise in complete compliance. That rumor sounds incredibly bogus. 1) How the hell are they going to discover if you support sockets? 2) Since the Woolongong TCP/IP package for the 3Bs running S5R2 provides a library that emulates the socket calls, it seems unlikely that they would a) want to or b) could get away with anathematizing them. From the first response: > Well, one point is that fstat doesn't work right on systems that use > sockets to support the PIPE system call. It can be made to do so with relatively little pain. 4.3 already ensures that the dev/inumber pair is unique, and stuffs a reasonable block size into "st_blksize"; the other reasons for doing an "fstat" might be 1) to see if the "st_mode" field says it's of type S_IFIFO, which can work if you stuff S_IFIFO|<permissions> into "st_mode", and 2) to see how much data is unread in the pipe by reading "st_size", which can work if you stuff so->so_rcv.sb_cc into "st_size". (I believe the feature in 2) may date back to V7, and thus would have worked in 4.1BSD as well if 32V had it also.) Alternatively, you could use something other than sockets to implement pipes.... -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)