> > [Armin] > > > You can already crash the interpreter with pure Python code, for example > > > via the new.code() constructor or by writing crappy .pyc files. [Guido] > > 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. [Armin] > Ok. I already more or less committed to have a serious look over > all the existing overflow problems that could cause a core dump > (http://www.python.org/sf/618623). I may add in my to-do list the > checks that no boggy data can crash unmarshall (after a first survey > of the code I'd say that such data might exist; e.g. r_string() has > a memcpy() that could be called with a negative size). Fixes for this and similar problems will be most welcome! > More importantly, if you think that there is use for a complete > "code object checker" that could catch any code doing silly things, > then I'd love to contribute. Note however that this is something > that will have to be kept closely in sync with future compiler > extensions. Yes, the fact that our VM isn't standardized makes this a bit tricky. But I think it ought to be done. --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