From owner-freebsd-bugs Thu Jul 18 19:10:16 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA11641 for bugs-outgoing; Thu, 18 Jul 1996 19:10:16 -0700 (PDT) Received: from scruz.net (nic.scruz.net [165.227.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA11631 for ; Thu, 18 Jul 1996 19:10:13 -0700 (PDT) Received: from Grizzly.COM by scruz.net (8.7.3/1.34) id TAA22626; Thu, 18 Jul 1996 19:09:52 -0700 (PDT) Received: (from markd@localhost) by Grizzly.COM (8.7.5/8.7.3) id TAA00823; Thu, 18 Jul 1996 19:10:19 -0700 (PDT) Date: Thu, 18 Jul 1996 19:10:19 -0700 (PDT) Message-Id: <199607190210.TAA00823@Grizzly.COM> From: Mark Diekhans To: joerg_wunsch@uriah.heep.sax.de, Bill Paul CC: FreeBSD-gnats-submit@freebsd.org, bugs@freefall.freebsd.org In-reply-to: <199607181648.SAA06346@uriah.heep.sax.de> (message from J Wunsch on Thu, 18 Jul 1996 18:48:35 +0200 (MET DST)) Subject: Re: kern/1397: can't send to a pipe Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi J"org and Bill, >From: J Wunsch >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 >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