Subject: bug#17467: 24.3; locate-library returning spurious path

From: Alex Kosorukoff <[email-masked]>
Date: Sun, 11 May 2014 13:45:12 -0700

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
<[email-masked]>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