[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.
Ken