[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#3892: corrupting load-in-progress value with "let"
From: |
Stefan Monnier |
Subject: |
bug#3892: corrupting load-in-progress value with "let" |
Date: |
Tue, 21 Jul 2009 12:27:05 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux) |
> 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