> On Tue, 8 Oct 2002 richie@entrian.com wrote:
> > (...) 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.
[Armin]
> You can already crash the interpreter with pure Python code, for example
> via the new.code() constructor or by writing crappy .pyc files.
Yes, and I occasionally lose sleep over those. I definitely don't
want to add more loopholes like that, and I'd like to fix those. In
the past, the new module was optional for precisely this reason (and
so is the dl module). I would like to have a check on .pyc files (or
on unmarshalled code objects, really).
> On Linux you can also open("/proc/self/mem", "w").
That doesn't mean that python should abandon the policy "a core dump
is always considered Python's fault unless proven otherwise."
Protecting you against using *external* tools may not be possible; but
Python should not include features (like writable code object
attributes) that can cause crashes when used inexpertly.
> I don't think that people get their hands on frame objects by pure
> chance, but the possibility exists. Moreover, conditionally
> allowing changes to f_lasti is limiting and complex because of the
> stack and block stack. For safety I'd consider writing the
> frame-object-modifying code in a C extension module, carefully
> documented as "don't use this".
That's a reasonable solution: f_lasti should be read-only from Python
code, but you can write an extension that can write it.
--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