Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-13 Thread Stephen Hansen
On 6/12/10 8:26 PM, Gregory Ewing wrote: On Jun 12, 6:05 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote: A programming goof, oversight or unexpected event causes an exception. It doesn't cause a buffer overflow. The important thing here isn't so much the exception as the *traceback*.

Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-13 Thread Stephen Hansen
On 6/12/10 8:42 PM, Gregory Ewing wrote: Stephen Hansen wrote: Its one thing for Python to make available foot-shooting tools(this is good! I love ctypes, with care) for the developer, its another thing entirely for it to shoot at the ground in the normal course of its operation and hope it

Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-13 Thread Terry Reedy
On 6/12/2010 11:42 PM, Gregory Ewing wrote: Seriously, though, if you can't trust someone to write safe ctypes-using code, can you trust them to write safe C code any better? No, and I think you are missing the concern about ctypes. There are two issues of ctypes versus safety/security:

safer ctype? (was GUIs - A modest Proposal)

2010-06-12 Thread Martin P. Hellwig
On 06/12/10 08:21, Martin v. Loewis wrote: cut The issue is not that you may mistakes in the ctypes code, thus allowing users to crash Python. The issue is that if users remove ctypes (which they may want to do because it's not trustworthy), then your module will stop working (unless you have a

Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-12 Thread Martin v. Loewis
Got me thinking, is it perhaps doable to have a 'safe' ctype that is guaranteed to be in the stdlib? Perhaps crippling it in a sense that it only allows a known set of functions to be called? In some sense, a C module wrapping a selected number of functions (like the win32 extensions) is

Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-12 Thread Bryan
Martin P. Hellwig wrote: Martin v. Loewis wrote: cut The issue is not that you may mistakes in the ctypes code, thus allowing users to crash Python. The issue is that if users remove ctypes (which they may want to do because it's not trustworthy), then your module will stop working

Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-12 Thread Martin v. Loewis
Perhaps instead of restricting what functions ctypes can use, we could restrict what modules can use ctypes. For example, maybe only modules in certain directories should be allowed to import ctypes. And that's indeed the case. The test suite may use ctypes. Regards, Martin --

Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-12 Thread lkcl
On Jun 12, 8:11 am, Martin v. Loewis mar...@v.loewis.de wrote: Got me thinking, is it perhaps doable to have a 'safe' ctype that is guaranteed to be in the stdlib? Perhaps crippling it in a sense that it only allows a known set of functions to be called? In some sense, a C module wrapping

Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-12 Thread Stephen Hansen
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.

Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-12 Thread lkcl
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

Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-12 Thread Stephen Hansen
On 6/12/10 12:46 PM, lkcl wrote: On Jun 12, 6:05 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote: 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

Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-12 Thread Martin v. Loewis
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.

Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-12 Thread Martin v. Loewis
ok... analogy: when using g++ to compile c++ code, would you place use of asm statements into the same sort of foot-shooting category? In a slightly different way, yes. There is no way of disabling inline assembly in g++, so the analogy is not fully appropriate. However, IIUC, using inline

Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-12 Thread Gregory Ewing
On Jun 12, 6:05 pm, Stephen Hansen me+list/pyt...@ixokai.io wrote: A programming goof, oversight or unexpected event causes an exception. It doesn't cause a buffer overflow. The important thing here isn't so much the exception as the *traceback*. When you've been programming in Python for a

Re: safer ctype? (was GUIs - A modest Proposal)

2010-06-12 Thread Gregory Ewing
Stephen Hansen wrote: Its one thing for Python to make available foot-shooting tools(this is good! I love ctypes, with care) for the developer, its another thing entirely for it to shoot at the ground in the normal course of its operation and hope it doesn't blow off any big toes. :) I would