GNU bug report logs - #17467
24.3; locate-library returning spurious path

Previous Next

Full log

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

From: Alex Kosorukoff <alex <at> 3form.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17467 <17467 <at> debbugs.gnu.org>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
Date: Sun, 11 May 2014 13:45:12 -0700

[Message part 1 (text/plain, inline)]

The issue is that locate-library returns spurious paths like ".*/tramp" or
".*xxx/tramp.gz" instead of returning a valid path to the library or nil if
no matching path is found. This is both unexpected and incorrect given this
function name and spec. It can cause user inconvenience or pose a
security/privacy issue because a random file named "tramp" or "tramp.gz"
placed in some directory of the load-path can be loaded instead of the
standard library without user knowledge. This is why I would prefer to fix
it.

On Sun, May 11, 2014 at 12:50 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca>wrote:

> > it should be just (".elc" ".elc.gz" ".el" ".el.gz") when nosuffix is nil.
>
> Why?
> Did you find some documentation indicating that this is how it should work?
> Or is it the behavior you'd prefer, and if so, can you explain why you'd
> prefer that behavior?  Which concrete cases do you specifically care about?
>

This was the first and simplest way to address the issue above. Eli
Zaretskii made a valid point that it is not consistent with the way this
function worked before and not the most convenient for the user. I agree
with this, so I posted a patch that handles the cases he described, except
that it addresses the issue above.

>
> The current behavior has been in use for *many* years and I expect that
> a fair bit of code relies on it, so we'd need a really good reason to
> change it.  Maybe we can accommodate your specific concrete cases in
> some other way.
>

I understand that the bug was there for many years and many
people implemented workarounds (I did). I don't think this is a valid
reason to keep it though. We just need to be careful to make sure we don't
introduce a regression while fixing it. Unit tests can help.


>
>
>         Stefan
>

[Message part 2 (text/html, inline)]

Previous Next

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