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

[Alex Kosorukoff]

Stefan is right that the bug was there for a long time. I would like my patch be compatible with older versions of emacs that don't have string-suffix-p, so here is the revised version

# Bazaar merge directive format 2 (Bazaar 0.90)

# revision_id: alex@3form.com-20140511205538-1asyz50g7d3y4lgw

# target_branch: :parent

# testament_sha1: d9ca6f57d0d8486d42ed77a739877a208a34f22e

# timestamp: 2014-05-11 13:55:53 -0700

# base_revision_id: monnier@iro.umontreal.ca-20140511034953-\

#   1mzcrftziwhrw9hl

# 

# Begin patch

=== modified file 'lisp/subr.el'

--- lisp/subr.el        2014-04-09 01:48:07 +0000

+++ lisp/subr.el        2014-05-11 20:55:38 +0000

@@ -1857,10 +1857,14 @@

                                        load-path (get-load-suffixes)))

                     nil nil

                     t))

-  (let ((file (locate-file library

-                          (or path load-path)

-                          (append (unless nosuffix (get-load-suffixes))

-                                  load-file-rep-suffixes))))

+  (let ((file

+         (locate-file library

+                      (or path load-path)

+                      (unless (or nosuffix

+                                  (string-match "\\.elc?\\.gz\\'" library))

+                        (if (string-match "\\.elc?\\'" library)

+                            load-file-rep-suffixes

+                          (get-load-suffixes))))))

     (if interactive-call

        (if file

            (message "Library is file %s" (abbreviate-file-name file))

# Begin bundle

IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWfbc99AABHZ/gDIwFUFQ4//3

8wgABL////BgBs96932joSoL3t0q2rG2TpgbVEE2kE9J6jNTyaZNNTagHqAAaaeoOYBNMAmQwABM

EwAAAShU02oAA0AAANAAAAG0qNQNT1MTCaepgmgwBDAI0000EUgRMgalP2mqaZpPVP0U9T0h6jah

kGJo0EVE0aaRgITaJMJoaRieoNAAZMyxwwqXQuSoc5zx7XqLgxjChKpd+GuM3swscixOW2FuYpwb

BJ76XVaN7ooEkNIl8j4H03G7ZaZmUngNpcGMaPziEkCQaXe13WIEZAjrzUVAplMmPv1v9TyDhZk/

TOCTEDcwOWPX5fOPrmzaublzrn8a9huAiuc8PAHYZNSwwjGhSFdSjC5SpYYbMwwpQrOXBEKJ3iZF

xMl+oRaRFCFZtuLh4YuClOwDzJ2cWwwkZCevW+rQM0X3eaEPAlD5B1eGOUYxZmw4cVlwgMkDZ3GZ

9AtqjnMIiLHfetqjn0CpARpIshrEt/05xJEWdXxLOe+NJoQjuMKkKlnUWzmFb+kN1g6CdRNKmoiP

XNismTs0wuRr35bDn4u+xGCEADgWqFbY5VAay3aHG6u7TB4iYIfEL7zJwFZoUJUM3c3+8duzI+Gw

TRDux3mtEOw6Q5pQdWZPmJiOJlrCNKcdm2BaHY/HpUhRgK0QoJtiadSVUybnyQxg9d/ZQTHS+Btw

7CqlMt1Lxhg65OAldu/FyOViFxXEMItpVgQNeBKhvHO8sS5hrOBR0qqutnrT+EWImQ5V23kQTlqx

Fd9ZIWwiyGqDeRU13oRurcJn2BtgIL6CS1uqhvgeodpiWMd+vZDjQTDE0HY5Uw6xPQahmK4du8xy

e2W5sXMjaOdRESRqGFxkVnUTqMqHoxIuLpmP/IdEJHApoJ1apwziupdVOEDpGWxWb7DEuLlM22QQ

HWza0l7xPf4ZYl72QOl+XZuqKiVvBkUiubNTzGuZihbGiGqmcryB2wyacpyqEoJRh29sQJmtZiZt

pFszcI94kc6nnwLmkkNifK9vqQuobBWhKhQLtXdG0hlrVXIqIOQyLL7DDcxheex8xPZKdjEMEytU

kzdrE3WxZsyEoyQhsxQbhLXMO90f2G6WyRYpm24mRjLZxKxYWUQXErpKlSbSTY97XjMdYvvZlTZD

ORCO615GiQTND6RrmmfrsoU7lnoZ3CefiGW4rk+sSgcjiR1pBIiSQSIl8np6nm2uInuxVqAqHwHE

JEX3WHA5m230El7Dobc9lW9l4cvcho8QPqh+IniDxPK2HCHlOtFMzOlPwPMOD0Dwz1a9DjU9BJY5

6Fu/mfa9fCHJF+x+5uqFMjn7XfhnHuG9j3JLFes6IXnEraIXdKYTeJGspva7eg4iYPXVDDsTQIC8

33xlGuvV5sEqFJROfJ8nfWm5hFm3CeftDC7At8jwuQx6fiWIcubjY+8XkVBUCgvxQFK2tK6JPofR

GtSFpRcJMQsVOp9gac33JNjR5jHMwBkAF6FH0LjRk7eT2aVLnZXFKQzqcSa6aDGntmRuUjRktEnl

aYpEbgXl2ntPa+jrU8dyLMNHsYaBmPkjiePIfAzO4h74eQO7ufN0Q7m15CQ20vAho8n6oQYhY6He

PMGoez7BMLgn0dGTqD8w94OT7Xm4P0YATa8hPUJ0DV4iZvRTYT1BBG4G5iL3ofJUtGxmnAcINyKK

RiV4/OVmEEKc04jYhEogyEkyCxDg9zkPa2ZhrCrIe9tUHFqzEqYJR0C0ZBY8EN6tQTihBDreFEMA

I+L8OoATB73QCwNXyE6u8EPlUh9Xg55E3LzE1vD1MMIRaY3OPGzghoJUiPyQxToJATEmpuCquN72

uweLq6XhgqGgSnuatYGAljGDRArjU6IiSlO1ptukSJDJ56MbIvaNyFhNA5vvYbODvIItsG+ODIqJ

Nm/oO5mMna3j7GiYdriN4mpGAiTOSG57XmhYhpBT4CSfgFrwa/WJ6IbkOAPkk2F749yGCFJM2CQR

YDBCaBWJ8xMR8RLx3eg6R4+TvDDZwf/F3JFOFCQ9tz30AA==

On Sun, May 11, 2014 at 1:45 PM, Alex Kosorukoff <alex@3form.com> wrote:

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