From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#36502: Fwd: bug#36502: 27.0.50; infinite loop in file-name-case-insensitive-p Date: Sat, 20 Jul 2019 19:32:30 -0700 Organization: UCLA Computer Science Department Message-ID: <715cb1de-9815-4229-993c-ecbf16da662a@cs.ucla.edu> References: <87muhr47k5.fsf@gmail.com> <837e8v87jf.fsf@gnu.org> <2ffa1b04-e667-f708-1047-d5fc38e72787@cornell.edu> <83v9wd7vwi.fsf@gnu.org> <14115c87-c1e7-6f3d-2694-106a9d4c8706@cornell.edu> <83bly47lxk.fsf@gnu.org> <837e8s7hk4.fsf@gnu.org> <2f71c7a3-423c-4a36-a0c2-5c1833905a28@cornell.edu> <2f15cf80-feba-3e71-4cbf-a7fa25b43797@cornell.edu> <83zhlo5tkm.fsf@gnu.org> <41c1033e-bd1c-d244-7293-00dfba900e8f@cornell.edu> <83v9w73gb5.fsf@gnu.org> <07659a69-b89e-51da-8bb3-adc32e1f39ae@cornell.edu> <09ed9fa5-efd8-93df-e4f1-dbd73cb1b823@cornell.edu> <83lfwtt650.fsf@gnu.org> <0a542a8e-67b8-b355-8fdf-f87d5b0cd1c5@cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="47693"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 Cc: "rms@gnu.org" , "schwab@suse.de" , "36502@debbugs.gnu.org" <36502@debbugs.gnu.org>, "npostavs@gmail.com" , "monnier@iro.umontreal.ca" , "dan@dpsutton.com" To: Ken Brown , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 21 04:33:10 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1hp1et-000CB3-LD for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Jul 2019 04:33:07 +0200 Original-Received: from localhost ([::1]:54310 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hp1es-0001vj-Gs for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Jul 2019 22:33:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35411) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hp1ep-0001vX-Ip for bug-gnu-emacs@gnu.org; Sat, 20 Jul 2019 22:33:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hp1eo-0001u3-EO for bug-gnu-emacs@gnu.org; Sat, 20 Jul 2019 22:33:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49227) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hp1eo-0001ty-AX for bug-gnu-emacs@gnu.org; Sat, 20 Jul 2019 22:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hp1eo-0004V0-61 for bug-gnu-emacs@gnu.org; Sat, 20 Jul 2019 22:33:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 Jul 2019 02:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36502 X-GNU-PR-Package: emacs Original-Received: via spool by 36502-submit@debbugs.gnu.org id=B36502.156367636217257 (code B ref 36502); Sun, 21 Jul 2019 02:33:02 +0000 Original-Received: (at 36502) by debbugs.gnu.org; 21 Jul 2019 02:32:42 +0000 Original-Received: from localhost ([127.0.0.1]:58047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hp1eU-0004UH-K1 for submit@debbugs.gnu.org; Sat, 20 Jul 2019 22:32:42 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:49902) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hp1eS-0004U3-5D for 36502@debbugs.gnu.org; Sat, 20 Jul 2019 22:32:41 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 829631626D6; Sat, 20 Jul 2019 19:32:34 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id PYFKAL3-1TED; Sat, 20 Jul 2019 19:32:33 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 798311626E0; Sat, 20 Jul 2019 19:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id g8_Df37XCiM0; Sat, 20 Jul 2019 19:32:33 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 30C241626D6; Sat, 20 Jul 2019 19:32:33 -0700 (PDT) In-Reply-To: <0a542a8e-67b8-b355-8fdf-f87d5b0cd1c5@cornell.edu> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:163500 Archived-At: Ken Brown wrote: >> The patch looks OK to me, but shouldn't we also make >> file-name-absolute-p recognize "~foo" as non-absolute when there's no >> user named "foo"? I thought we agreed this is a discrepancy we don't >> want. > I'm not sure. The current behavior is longstanding and was explicitly > documented by Paul (added to the CC) in the last couple years. Might there be > some code that relies on this behavior? As I recall, I documented it because of the confusion encountered when dealing with Bug#28156 (Emacs quietly munges symlink contents). I looked into the history of file-name-absolute-p back to 1991. Although the current behavior is indeed longstanding, I don't think it was originally intended to treat ~foo/x as absolute when "foo" is not a valid username. I think the code was originally written under the assumption that this case was not worth worrying about. My impression from looking at uses of file-name-absolute-p is that changing it to return nil here would improve correctness of the callers, though there would be a performance cost for this case of course.