Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Jul 1996 19:20:03 -0700 (PDT)
From:      Mark Diekhans <markd@Grizzly.COM>
To:        freebsd-bugs
Subject:   Re: kern/1397: can't send to a pipe
Message-ID:  <199607190220.TAA12555@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607190220.TAA12555>