bug#79762: Guile may run stale code if source changes too quickly

Rob Browning wrote:
> In the past I'd noticed that guile appeared to be running stale code,
> and I finally got a chance to track it down with help from Dale Smith.
>
> The cause is that filesystems have finite (and sometimes quite coarse)
> timestamp "granularity", and guile currently treats equal timestamps
> between a .scm file and .go file as meaning that the .go file is up to
> date, i.e. represents the compilation of the code in the .scm
> file. Right now that is not always true, and can produce undesiarable
> results:
>
> For example, if you do this:
>
>   echo '(display "something bad\n")' > test.scm
>   guile test.scm
>   echo '(display "the (broken) fix)' > test.scm
>   guile test.scm

This is an artificial example.  In what situation did you encounter
this issue?  I am wondering if it is easier to fix that situation
instead of submitting this patch.

> The final guile invocation may actually succeed while printing
> "something bad" if the test.go generated by the first guile invocation
> ends up with the same timestamp as the one with the fix. It's not even
> relevant that the fix is actually itself broken (invalid syntax) because
> guile never attempts to compile it --- it just runs the "bad" test.go.
>
> To fix this, we can change compiled_is_fresh in load.c to require the
> .go to be strictly newer than the corresponding .scm, i.e. change the <=
> to < here:

If you do that, you will break a lot of Guile Autotools projects whose
object files currently have >= timestamps to sources.  See for example
<https://lists.gnu.org/archive/html/guile-devel/2010-07/msg00125.html>,
which explains an Automake hack to establish

  object timestamp >= source timestamp.

To obtain a strict inequality, a sleep command would further need to
be used (as discussed there), but currently autotools projects do not
do this and will break with your patch.

Regards,
Nikolaos Chatzikonstantinou