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

Previous Next

To reply to this bug, email your comments to 18835 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Geert Janssens <info <at> kobaltwit.be>
To: bug-guile <at> gnu.org
Subject: load-from-path is inconsistent when looking for a compiled version of
 the source file
Date: Sat, 25 Oct 2014 19:09:09 +0200

[Message part 1 (text/plain, inline)]

$ guile --version
guile (GNU Guile) 2.0.11

$ config.guess 
x86_64-unknown-linux-gnu

$ rpm -qa | grep guile
compat-guile18-1.8.8-7.fc20.x86_64
guile-debuginfo-2.0.11-1.fc20.x86_64
guile-2.0.11-1.fc20.x86_64
guile-devel-2.0.11-1.fc20.x86_64

These steps illustrate the issue:

1. Download the attached file and save it as $HOME/guile/test.scm
Note: this is just an example file printing one line to indicate is has
successfully been called. Any other scm file will do to illustrate this bug.

2. Run these commands:
$ mkdir -p $HOME/guile/ccache
$ cd $HOME/guile/ccache
$ guild compile -o test.go ../test.scm
$ guild compile -o test.scm.go ../test.scm

This will generate two compiled versions of the test file, each with a different extension.

Now run these commands and observe what happens:
$ cd $HOME/guile
$ GUILE_LOAD_PATH=$HOME/guile \
  GUILE_LOAD_COMPILED_PATH=$HOME/guile/ccache \
  guile -c '(load-from-path "test")'

=> This command will use the file $HOME/guile/ccache/test.go. That is, no auto-compilation 
is triggered.

$ GUILE_LOAD_PATH=$HOME/guile \
  GUILE_LOAD_COMPILED_PATH=$HOME/guile/ccache \
  guile -c '(load-from-path "test.scm")'

=> This command will *not* use either of $HOME/guile/ccache/test.go or 
$HOME/guile/ccache/test.scm.go. Instead it will autocompile test.scm into <default-cache-
dir>/test.scm.go and use that one.

So there is no way to have the second command use your self-compiled files.

From Andy Wingo's comments on irc, it is expected that the second case would have used the 
self-compiled $HOME/guile/ccache/test.scm.go. I'm fine with that although using 
$HOME/guile/ccache/test.go would have made more sense from an outsider's point of view. At 
least it should be possible to make load-from-path use a self-compiled .go file regardless of 
whether the argument ends in .scm or not.

If more information is needed, feel free to ask.

Regards,

Geert

[Message part 2 (text/html, inline)]

[test.scm (text/x-scheme, attachment)]

Message #8 received at 18835 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: Geert Janssens <info <at> kobaltwit.be>
Cc: 18835 <at> debbugs.gnu.org
Subject: Re: bug#18835: load-from-path is inconsistent when looking for a
 compiled version of the source file
Date: Wed, 22 Jun 2016 10:28:52 +0200

On Sat 25 Oct 2014 19:09, Geert Janssens <info <at> kobaltwit.be> writes:

> $ guild compile -o test.scm.go ../test.scm
>
> $ GUILE_LOAD_PATH=$HOME/guile \
>
> GUILE_LOAD_COMPILED_PATH=$HOME/guile/ccache \
>
> guile -c '(load-from-path "test.scm")'
>
> => This command will *not* use either of $HOME/guile/ccache/test.go or
> $HOME/guile/ccache/test.scm.go. Instead it will autocompile test.scm
> into <default-cache-dir>/test.scm.go and use that one.

Weird.  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.

Andy

Message #11 received at 18835 <at> debbugs.gnu.org (full text, mbox):

From: Taylan Kammer <taylan.kammer <at> gmail.com>
To: 18835 <at> debbugs.gnu.org, Andy Wingo <wingo <at> pobox.com>
Subject: load-from-path is inconsistent when looking for a compiled version of
 the source file
Date: Mon, 17 May 2021 22:25:48 +0200

[Message part 1 (text/plain, inline)]

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 (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.