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.sig>


More information about the Python-list mailing list