bug#3892: corrupting load-in-progress value with "let"

[Stefan Monnier <monnier@iro.umontreal.ca>]

> The variable load-in-progress is defined in the C code with DEFVAR_BOOL
> applied to an int variable.  Since file loading can be  invoked recursively,
> the int value is incremented and decremented when  loading begins and ends,
> and should in theory be zero only when no  file is being loaded.

> However, if we're loading a .el file from source, the C code in
> lread.c:Fload calls out to the load-source-file-function, which winds  up
> calling code in mule.el, which uses "let" on load-in-progress.
> The  let/unwind support doesn't save and restore the integer value for
> a  Lisp_Misc_Boolfwd variable, just the boolean state.  So after loading  of
> test3.el finishes above, load-in-progress is restored from its old
> *boolean* value, and gets the value 1 instead of 2 as it should have.
> When test2.elc is done loading, it drops to zero and it looks like  we're
> not currently loading any files, even though we're in the middle  of loading
> test.elc still.

Good catch.

> On the assumption that DEFVAR_BOOL variables really ought to just be used as
> booleans (I haven't checked other boolean variables though),  and we don't
> want to change the Lisp-visible binding to an integer (or "if
> load-in-progress" would stop working right), I'm working on a  patch to make
> load-in-progress an actual boolean, and put the file-
> loading depth counter elsewhere, inaccessible to Lisp (since it's
> inaccessible now).

I think we should drop the counter altogether, and use specbind instead.


        Stefan