[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ken Raeburn
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]