GNU bug report logs - #36502
27.0.50; infinite loop in file-name-case-insensitive-p

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ken Brown <kbrown <at> cornell.edu>, Eli Zaretskii <eliz <at> gnu.org>
Cc: "rms <at> gnu.org" <rms <at> gnu.org>, "schwab <at> suse.de" <schwab <at> suse.de>, "npostavs <at> gmail.com" <npostavs <at> gmail.com>, "36502 <at> debbugs.gnu.org" <36502 <at> debbugs.gnu.org>, "monnier <at> iro.umontreal.ca" <monnier <at> iro.umontreal.ca>, "dan <at> dpsutton.com" <dan <at> dpsutton.com>
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

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.