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

Previous Next

Full log

Message #31 received at 36502 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "dan <at> dpsutton.com" <dan <at> dpsutton.com>,
 "npostavs <at> gmail.com" <npostavs <at> gmail.com>,
 "36502 <at> debbugs.gnu.org" <36502 <at> debbugs.gnu.org>
Subject: Re: bug#36502: Fwd: bug#36502: 27.0.50; infinite loop in
 file-name-case-insensitive-p
Date: Sun, 7 Jul 2019 14:09:03 +0000

On 7/6/2019 12:14 PM, Eli Zaretskii wrote:
>> From: Ken Brown <kbrown <at> cornell.edu>
>> Date: Sat, 6 Jul 2019 15:38:14 +0000
>> Cc: "36502 <at> debbugs.gnu.org" <36502 <at> debbugs.gnu.org>
>>
>>> +      && !NILP (Ffile_name_absolute_p (filename)))
>>>        {
>>>          filename = Ffile_name_directory (filename);
>>>          while (NILP (Ffile_exists_p (filename)))
>>>
>>> Or maybe signal an error, either way seems better than just getting stuck.
>>
>> Maybe expand-file-name should signal an error if default-directory is
>> relative?
> 
> That'd not be my first preference.  My first preference would be to
> detect the cases where we are about to loop.  Can we do that?

The only case I can think of where we might loop is the case we're discussing, 
in which expand-file-name fails to return an absolute name.  Noam's patch is 
fine for that case.  But wouldn't it be better to fix expand-file-name so that 
it always returns an absolute name, as it's documented to do?

Ken

Previous Next

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