From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Vivek Newsgroups: gmane.emacs.devel Subject: Re: insert-file-contents and fifos Date: Mon, 6 May 2002 16:26:35 +0100 (BST) Sender: emacs-devel-admin@gnu.org Message-ID: References: <200205060624.g466OTZ01973@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1020698877 30152 127.0.0.1 (6 May 2002 15:27:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 6 May 2002 15:27:57 +0000 (UTC) Cc: "emacs-devel@gnu.org" Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 174kP6-0007qD-00 for ; Mon, 06 May 2002 17:27:56 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 174kWJ-0001LE-00 for ; Mon, 06 May 2002 17:35:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 174kOf-0002S8-00; Mon, 06 May 2002 11:27:29 -0400 Original-Received: from salmon.pepperfish.net ([195.149.39.195]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 174kNp-0002Is-00; Mon, 06 May 2002 11:26:38 -0400 Original-Received: from localhost ([127.0.0.1]) by salmon.pepperfish.net with esmtp (Exim 3.35 #1 (Debian)) id 174kNn-00085j-00; Mon, 06 May 2002 16:26:35 +0100 X-X-Sender: Original-To: Richard Stallman In-Reply-To: <200205060624.g466OTZ01973@aztec.santafe.edu> Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:3639 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3639 On Mon, 6 May 2002, Richard Stallman wrote: > GNU emacs 20 was capable of reading from this, 21 is not. The change > appears to be the introduction of the new read_non_regular function > in fileio.c : a strace shows emacs fetching the data from the file > ( you can see the data being read ), and then aborting. Presumably > the state of a fifo is sufficiently different from a non-regular file > that read_non_regular reacts as if an error has occurred. > > Could you step through it and see why this happens? > The code looks straightforward, so I don't see why it would fail. Maybe I'm being dense, or just don't understand what the code is meant to do, but: `read_non_regular' _always_ calls Fsignal (Qquit, Qnil); just after `emacs_read' (which succeeds, afaict) and the call to `read_non_regular' in `insert-file-contents' is wrapped in an `internal_condition_case_1' call: so is it _ever_ possible for a read of a non regular file to succeed, since: val = internal_condition_case_1 ( read_non_regular, Qnil, Qerror, read_non_regular_quit ); if (NILP (val)) { read_quit = 1; break; } So, according to my (albeit limited) understanding, we're calling internal_condition_case_1, which calls read_non_regular, which will _always_ signal '(quit . nil), which will therefore always result in a 'nil return from internal_condition_case_1 : can insert-file-contents read any non regular files at all? I tried with both ~/.sig-dyn and /dev/fd0 and both resulted in the same behaviour: a successful read(2) of the available data (or the first 65536 bytes in thcase of /dev/fd0) followed by a bailout. I'm confused... for the record, here's the read_non_regular that I have: static Lisp_Object read_non_regular () { int nbytes; immediate_quit = 1; QUIT; nbytes = emacs_read (non_regular_fd, BEG_ADDR + PT_BYTE - 1 + non_regular_inserted, non_regular_nbytes); Fsignal (Qquit, Qnil); immediate_quit = 0; return make_number (nbytes); }