bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alex Kosorukoff
Subject: bug#17467: 24.3; locate-library returning spurious path
Date: Sun, 11 May 2014 14:00:48 -0700

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: address@hidden
# target_branch: :parent
# testament_sha1: d9ca6f57d0d8486d42ed77a739877a208a34f22e
# timestamp: 2014-05-11 13:55:53 -0700
# base_revision_id: address@hidden
#   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 <address@hidden> 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 <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]