GNU bug report logs - #3892
corrupting load-in-progress value with "let"

Previous Next

Full log

View this message in rfc822 format

From: Ken Raeburn <raeburn <at> raeburn.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 3892 <at> debbugs.gnu.org
Subject: bug#3892: corrupting load-in-progress value with "let"
Date: Thu, 23 Jul 2009 21:51:01 -0400

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

Previous Next

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