On Jun 12, 6:05 pm, Stephen Hansen <me+list/pyt...@ixokai.io> wrote: > 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
[i knew this would be the / an / something-like-the answer, but i'm just... "reading the script" so to speak] > 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. ok... analogy: when using g++ to compile c++ code, would you place use of "asm" statements into the same sort of foot-shooting category? > 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. :) teehee :) -- http://mail.python.org/mailman/listinfo/python-list
