"Tim Peters" <tim.one at comcast.net> writes: > Examples of things that aren't checked at all now in the PVM were given > before, like the PVM doesn't check that it allocated enough stack space, or > check that C-level indexing into the co_consts vector is in bounds. Well, > in the latter case, that is checked (at runtime, on every co_consts access) > in a debug build, but not in a release build. I think stack over/underflow is checked in a debug build too. So here's a way to plug these holes: run a debug build the whole time :-) It's only, what, a factor of 3 performance hit. If people are seriously concerned about preventing Python coring in all circumstances, we should look at the various ways of overflowing the stack, too. The recursion counter is a hack, and IMHO can't be made to work sensibly. For instance: list_sort() has quite a large structure on the stack, so if you arrange to call it recursively it falls off the end of the stack much much sooner than a simple Python recursion. I don't know what we can do about this. Armin suggested another hack: stick the address of a stack variable in Py_Main() in a global and compare the address of another stack variable when you want to see how much stack you have left. Obvious problems include knowing what's safe and which direction the stack is growing in... Even more scarily, what SBCL (a Common Lisp implementation) does is mprotect() a VM page and the end of the stack and deal with overflow in a SIGSEGV handler. It's hard to see what else could be really safe (have I mentioned that I hate C recently?). Option 3, I guess, is integrate stackless :-) Cheers, mwh -- 8. A programming language is low level when its programs require attention to the irrelevant. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
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