From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Improve reporting of I/O, access errors for Emacs Date: Fri, 13 Sep 2019 10:37:52 +0300 Message-ID: <8336h01wa7.fsf@gnu.org> References: <83d0g51jdp.fsf@gnu.org> <83a7b91f6l.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="69553"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 13 09:38:15 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i8g9n-000Hxx-FB for ged-emacs-devel@m.gmane.org; Fri, 13 Sep 2019 09:38:15 +0200 Original-Received: from localhost ([::1]:40960 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i8g9m-0006zU-D3 for ged-emacs-devel@m.gmane.org; Fri, 13 Sep 2019 03:38:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35783) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i8g9D-0006yG-Lk for Emacs-devel@gnu.org; Fri, 13 Sep 2019 03:37:40 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48880) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i8g9D-0003nW-9M; Fri, 13 Sep 2019 03:37:39 -0400 Original-Received: from [176.228.60.248] (port=2757 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i8g9C-0002F6-MH; Fri, 13 Sep 2019 03:37:39 -0400 In-reply-to: (message from Paul Eggert on Thu, 12 Sep 2019 13:32:16 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:240009 Archived-At: > Cc: Emacs-devel@gnu.org > From: Paul Eggert > Date: Thu, 12 Sep 2019 13:32:16 -0700 > > On 9/12/19 12:34 PM, Eli Zaretskii wrote: > > We should just set > > errno and return an error indication, and then let the caller deal > > with that. > > I don't see how that could work. Callers are typically written in Lisp, > and so can't see errno. There's some kind of misunderstanding here: the 3 functions I mentioned are not Lisp-callable, they are called, directly or indirectly, by Lisp primitives written in C. My point was that in the code of the primitive itself, we have all the information to decide whether or not to signal an error; but on lower levels, we don't have enough context to make such decisions, so we should only return an error indication from those lower levels. > For example, suppose Lisp code calls (file-symlink-p "/a/b/c") and Emacs > cannot tell whether /a/b/c is a symbolic link because of an I/O error, > or because of a timeout in network access, or because /a is a symlink > into an unreadable directory, or whatever. If file-symlink-p merely > returns nil, there's no way for the Lisp code to know that there was an > exceptional situation and the Lisp code will continue based on the > incorrect assumption that /a/b/c was not a symlink. I agree that file-symlink-p, being a primitive, can decide to signal an error in case of I/O errors. But I wasn't talking about the level of primitives, I was talking about lower levels. E.g., file_directory_p has no way of making intelligent decisions regarding whether its caller should or shouldn't signal an error in some case, because file_directory_p can be called in a variety of use cases and contexts, about whose details it knows nothing at all. > > That's too small a sample, so it doesn't prove much in my book, sorry. > > I've looked at and experimented with a reasonable amount of Elisp code, > and haven't run into problems with the proposed patch. What's your > contrary intuition based on? Can you give a realistic example of the > problems you see from the patch? See above: it sounds wrong to delegate to very low levels an authority of failing the entire higher-level application, since those low levels don't have enough context information to make such decisions.