Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!lll-crg!lll-lcc!pyramid!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.unix-wizards,net.unix
Subject: Re:  Rumor about AT&T Validation
Message-ID: <6005@sun.uucp>
Date: Sat, 9-Aug-86 14:43:55 EDT
Article-I.D.: sun.6005
Posted: Sat Aug  9 14:43:55 1986
Date-Received: Mon, 11-Aug-86 04:14:34 EDT
References: <2842@brl-smoke.ARPA> <2846@brl-smoke.ARPA>
Organization: Sun Microsystems, Inc.
Lines: 32
Xref: watmath net.unix-wizards:19155 net.unix:8870

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)