On 6/12/10 9:55 AM, lkcl wrote: > On Jun 12, 8:11 am, "Martin v. Loewis" <mar...@v.loewis.de> wrote: >> Notice that it's not (only) the functions itself, but also the >> parameters. It's absolutely easy to crash Python by calling a function >> through ctypes that expects a pointer, and you pass an integer. The >> machine code will dereference the pointer (trusting that it actually is >> one), and crash. > > what's so bad about that? (this is a genuine, non-hostile, non- > rhetorical, non-sarcastic question). > > (if the answer is "because you can't catch a segfault as a python > exception", then the question is repeated)
... ?! Its not OK for code written in Python to cause a segfault; its not OK for Python to error out in such a way that Python-level code can't catch and deal with the error or situation (Or, at least, make note of the traceback for later, in cases where there really isn't anything the Python-level code could have done about it). Its one of the reasons why we *like* Python at my day job. (Though it applies to nearly any other high level language): its inherently safer. A programming goof, oversight or unexpected event causes an exception. It doesn't cause a buffer overflow. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ P.S. Yes, I do understand that ctypes invalidates those assumptions. And that's OK. Every once in awhile, with great care and research to make sure I know what I'm doing, I'll take the risk anyways. I do understand the policy in terms of the stdlib though. I just wish it didn't apply to win32 API's somehow. No, I know its not at all logical. Leave me alone. :)
signature.asc
Description: OpenPGP digital signature
-- http://mail.python.org/mailman/listinfo/python-list
