From owner-freebsd-bugs  Thu Jul 18 19:20:04 1996
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id TAA12587
          for bugs-outgoing; Thu, 18 Jul 1996 19:20:04 -0700 (PDT)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id TAA12555;
          Thu, 18 Jul 1996 19:20:03 -0700 (PDT)
Date: Thu, 18 Jul 1996 19:20:03 -0700 (PDT)
Message-Id: <199607190220.TAA12555@freefall.freebsd.org>
To: freebsd-bugs
Cc: 
From: Mark Diekhans <markd@Grizzly.COM>
Subject: Re: kern/1397: can't send to a pipe
Reply-To: Mark Diekhans <markd@Grizzly.COM>
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR kern/1397; it has been noted by GNATS.

From: Mark Diekhans <markd@Grizzly.COM>
To: joerg_wunsch@uriah.heep.sax.de, Bill Paul <wpaul@skynet.ctr.columbia.edu>
Cc: FreeBSD-gnats-submit@freebsd.org, bugs@freefall.freebsd.org
Subject: Re: kern/1397: can't send to a pipe
Date: Thu, 18 Jul 1996 19:10:19 -0700 (PDT)

 Hi J"org and Bill,
 
 >From: J Wunsch <j@uriah.heep.sax.de>
 
 >Pipes are no longer implemented as sockets.  Using socket operations
 >on them was illegal all the time, even if the kernel has not been
 >reporting the error.
 
 Cool, I always though sockets were a little overkill for pipes...
 
 >From: Bill Paul <wpaul@skynet.ctr.columbia.edu>
 
 >He didn't mean fstat(1), he meant fstat(2). Look at the sample source
 >he supplied: he's calling fstat(2) on one of the pipe descriptors
 >returned by pipe(2) and he says he's getting S_IFSOCK as a result.
 >However since John's new pipe code does not in fact (ab)use sockets,
 >attempts to use socket system calls on the descriptors fail. This
 >is a contradiction: if socket operations won't work, fstat(2) should
 >not identify the descriptors as S_IFSOCK.
 
 Exactly!
 
 
 >In this case, he could replace pipe(2) with socketpair(2) in the
 
 The code (a Tcl extension) I am dealing with has an open file descriptor and
 tries to figure out what to do with it, so this isn't a solution. It uses
 send on sockets since its more reliable.
 
 >application, but that doesn't change the fact that fstat(2) is reporting 
 >a bogus result. I suppose a new type has to be added (S_IPIPE?), but
 >a question (in my mind at least) of compatibility with other *BSD systems.
 
 Reporting FIFO would probably be better than SOCK, at least that wouldn't
 lead people to do the wrong thing because they think its a socket.
 
 Given all of this, the definition of S_ISFIFO probably is wrong as well:
 
 #define	S_ISFIFO(m)	(((m) & 0170000) == 0010000 || \
 			 ((m) & 0170000) == 0140000)	/* fifo or socket */
 
 
 
 Mark