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

[Alex Kosorukoff]

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@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