safer ctype? (was GUIs - A modest Proposal)
Stephen Hansen
me+list/python at ixokai.io
Sat Jun 12 14:05:16 EDT 2010
On 6/12/10 9:55 AM, lkcl wrote:
> On Jun 12, 8:11 am, "Martin v. Loewis" <mar... at 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. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20100612/c6ec63fd/attachment-0001.sig>
More information about the Python-list
mailing list