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

[Ken Raeburn <raeburn@raeburn.org>]

On Jul 23, 2009, at 21:14, Stefan Monnier wrote:
>> I'm working on the revised patch, but it occurs to me that this  
>> way, some
>> broken bit of code could set load-in-progress to t at some point   
>> when
>> nothing is being loaded, and it will never become nil again  unless
>> explicitly reset.
>
> Isn't that a problem that already exists?

Not exactly... in the released code (and trunk before my first  
change), it can explicitly be set to t at the top level, but it'll be  
reset to nil after loading another file.  And, the bug I was aiming to  
fix initially, the counter (unseen by Lisp) can be set to 1 from some  
higher number during nested loading, causing it to be set to nil when  
returning back to enclosing load calls, but once you get back to the  
top level the nil value is correct, and when the next load starts from  
the top level it'll correctly be set to t (temporarily) again.

So the specbind version would make the first bug a little worse,  
though it fixes the second.

> In any case such setting would be a bug, so I wouldn't worry about it.

Yeah, that's true enough...

>> A related issue: If we're changing the way it's set, should we  
>> retain the
>> constraint that load-in-progress can only (appear to) hold boolean   
>> values,
>> or let it hold any Lisp value instead?
>
> A boolean seems sufficient, I see no need to change it for now,

Okay, it doesn't seem like a big deal to me either way.

Ken