bug#18835: load-from-path is inconsistent when looking for a compiled version of the source file

[Taylan Kammer]

In 2016, Andy wrote:

> The logic in load.c is that we only add on .go if the file
> doesn't already have an extension.  If the file has an extension and
> it's not .go, then we don't grovel in the path at all.  I guess this is
> the wrong thing?
> 
> I am not sure if we can change this in 2.0 or not.  I guess we can.

Well that ship has sailed anyway. ;-)

IMO we should change the behavior to always try to add extensions, after
first trying without an extension.

It's feasible that one might choose to name one's files like foo.bar.scm
and the like, in which case trying to load foo.bar should work.  I might
name a number of files foo.v1.scm, foo.v2.scm, and so on.  Alternatively,
consider the already popular foo.upstream.scm.

Further, I don't see any possible confusion arising from adding the
extensions.  No one would name their files foo.go.scm or foo.scm.scm and
then try to load "foo.go" or "foo.scm" and expect the one with an extra
.scm to be loaded.

I thought a bit whether there might be security implications, like when
dropping files into a directory where every user can create files, and
someone could maliciously put a foo.scm.scm to take precedence over your
foo.scm, but that's already a problem as they could drop in a foo.go, so
the solution is not to try to load files from directories you can't trust,
like /tmp.

The only compatibility issue I can think of: maybe some people put both a
file foo and a file foo.scm in the same directory, and expect (load "foo")
to *not* try to load the one without an extension.

Thoughts?


Attached is a patch that would implement the suggestion of trying without
an extension first, then with an extension, without checking whether the
original filename does or doesn't have an extension.

-- 
Taylan

0001-Make-load-try-to-add-an-extension-to-files-that-alre.patch
Description: Text document