> *** frameobject.c Tue Oct 8 08:16:39 2002
> --- frameobject-222b1.c Tue Oct 8 08:16:12 2002
> ***************
> *** 16,20 ****
> {"f_builtins", T_OBJECT, OFF(f_builtins),RO},
> {"f_globals", T_OBJECT, OFF(f_globals), RO},
> ! {"f_lasti", T_INT, OFF(f_lasti)},
> {"f_lineno", T_INT, OFF(f_lineno), RO},
> {"f_restricted",T_INT, OFF(f_restricted),RO},
> --- 16,20 ----
> {"f_builtins", T_OBJECT, OFF(f_builtins),RO},
> {"f_globals", T_OBJECT, OFF(f_globals), RO},
> ! {"f_lasti", T_INT, OFF(f_lasti), RO},
> {"f_lineno", T_INT, OFF(f_lineno), RO},
> {"f_restricted",T_INT, OFF(f_restricted),RO},
A backwards diff! He posted a backwards diff! Aargh! :-)
> Is this a reasonable suggestion for 2.3, or is it giving people too
> much rope? A nasty consequence is that you can write Python code
> that causes Python to seg-fault, but you have to be doing some
> fairly advanced stuff for that to happen. I would say that the
> power of a Set-next-statement feature in pdb and other debuggers is
> worth the price, but others may disagree...?
I can't approve a Python-level feature that explicitly opens up a
loophole of this kind. But if you add a C "getset" wrapper that
allows setting this only to safe values (i.e. within the same block
and pointing at the beginning of a bytecode) it might be deemed safe
enough. It should probably silently update f_lineno as well. Spare
no cost. It's up to you to write the patch, submit it to SF, and
prove that it's safe.
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4