[Python-Dev] another dict crasher

Tim Peters tim.one@home.com
Sun, 3 Jun 2001 19:03:31 -0400


[Tim]
>> It would be better in this case to go back to the top and start
>> over.

[Michael Hudson]
> Yes.  What you checked in is obviously better.  I'll stick to being
> the bearer of bad tidings...

Hey, if it's fun, do whatever what you want!  If you hadn't provoked me, I
would have let it slide.  Guido only cares about the end result <wink>.

>> However, then an adversarial user can construct a case that never
>> terminates.

> I seem to have done this - it was odd, though - it only loops when I
> bump the dict to fairly enormous preportions for reasons I don't
> really (want to) understand.

Pass it on.  I deliberately "started over" via a recursive call instead of a
goto so that an offending program would eventually die with a stack fault
instead of just running forever.  So if you're seeing something run forever,
it may be a different problem.

>> Unclear what to do.

> Not worrying about it seems entirely reasonable

I don't think anyone is happy leaving an exploitable hole in Python -- we
endure enormous pain to plug those.  Except, I guess, for buffer objects
<wink>.  I simply haven't thought of a good and efficient way to plug this
one.  Implementing an "internal immutable dict" type appeals to me, but it
conflicts with that the affected routines believe to the core of their souls
that exceptions raised during comparisons are to be ignored -- and raising a
"hey, you can't change the dict *now*!" exception doesn't do the user any
good if they never see it.  Would plug the hole, but an *innocent* user
would never know why their program failed to work as (probably) expected.