discuss: [Squeak 0001144]: [ENH] SmartSyntaxInterpreterPlugin

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

discuss: [Squeak 0001144]: [ENH] SmartSyntaxInterpreterPlugin

Martin Kuball
Hi!

I know this is more than a year in the past. But some things take
their time and I'v just now resumed my work on the Xvid plugin.

When evaluating my sugested changes, Andreas made the following
comment:

> The main reason for concern is that this creates a dangerous
> precedent for plugins. Thus far, all plugins have been "safe" in
> such that they were used with unforgeable object references.
> Allowing arbitrary pointers in *plugin* interfaces means that the
> whole idea of "plugins are secure, FFI is not" becomes moot.    
>
> Suddenly we need to be aware which plugins abuse what pointers and I
> think we should really avoid this. I have not looked at the specific
> reason for wanting to pass a pointer instead of an object reference
> but the only reason I can imagine is that the pointer was
> originally obtained by some FFI call. In which case I'd say "stick
> with FFI" instead of plugins (after all it's no harder to export a C
> function from a plugin than to write the named primitive).
>
> There are no good reasons that I can think of to suddenly start
> using C pointers in plugins (lazyness on behalf of the plugin writer
> does not count) and there are many good reasons against it.

Unfortunately I do not realy understand his arguments. From the code
of the plugins that come with VMMaker I can see that there are
plugins that use c-pointers and do pass them to smalltalk. E.g. the
Mpeg3 Plugin does it and the OsProecess plugin is another example.

I would be very glad if someone could explain to me what is allowed
and what is forbidden regarding this matter.

Thanks.

Martin

Reply | Threaded
Open this post in threaded view
|

Re: discuss: [Squeak 0001144]: [ENH] SmartSyntaxInterpreterPlugin

David T. Lewis
On Sat, Aug 19, 2006 at 09:17:11PM +0200, Martin Kuball wrote:

>
> When evaluating my sugested changes, Andreas made the following
> comment:
> >
> > There are no good reasons that I can think of to suddenly start
> > using C pointers in plugins (lazyness on behalf of the plugin writer
> > does not count) and there are many good reasons against it.
>
> Unfortunately I do not realy understand his arguments. From the code
> of the plugins that come with VMMaker I can see that there are
> plugins that use c-pointers and do pass them to smalltalk. E.g. the
> Mpeg3 Plugin does it and the OsProecess plugin is another example.

I don't remember having done this in OSProcessPlugin. I did lots of
other horrible things, but I did not pass any C pointers to or from
primitives.  Signal handlers, aio event handlers and the like require
function pointers, but there is no need pass these pointers to or from
the image.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: discuss: [Squeak 0001144]: [ENH] SmartSyntaxInterpreterPlugin

Martin Kuball
Am Sunday, 20. August 2006 00:16 schrieb David T. Lewis:

> On Sat, Aug 19, 2006 at 09:17:11PM +0200, Martin Kuball wrote:
> > When evaluating my sugested changes, Andreas made the following
> >
> > comment:
> > > There are no good reasons that I can think of to suddenly start
> > > using C pointers in plugins (lazyness on behalf of the plugin writer
> > > does not count) and there are many good reasons against it.
> >
> > Unfortunately I do not realy understand his arguments. From the code
> > of the plugins that come with VMMaker I can see that there are
> > plugins that use c-pointers and do pass them to smalltalk. E.g. the
> > Mpeg3 Plugin does it and the OsProecess plugin is another example.
>
> I don't remember having done this in OSProcessPlugin. I did lots of
> other horrible things, but I did not pass any C pointers to or from
> primitives.  Signal handlers, aio event handlers and the like require
> function pointers, but there is no need pass these pointers to or from
> the image.

Well here's what I understand by looking at your code. Let's take
primitiveCreatePipe. It returns an array with two ByteArrays in it that
contain information about the reader and the writer of the pipe. Let's
take the first ByteArray, the writer. You create it, take the pointer to
the bytes and interpret them as a struct of type SQFile. Than you set the
field "file" inside the struct to the value of writerIOStream which is (on
unix) a pointer to a FILE structrue optained from a call to fdopen.

        writer _ self newSQFileByteArray.
        writerPtr _ self fileValueOf: writer.
        self cCode: 'writerPtr->file = writerIOStream'.

So to me this looks very much like you'r passing pointers to C data
structures to the image. But I admit that I might still not really
understand this plugin stuff.

Martin

Reply | Threaded
Open this post in threaded view
|

Re: discuss: [Squeak 0001144]: [ENH] SmartSyntaxInterpreterPlugin

David T. Lewis
On Sun, Aug 20, 2006 at 11:40:44AM +0200, Martin Kuball wrote:

> Am Sunday, 20. August 2006 00:16 schrieb David T. Lewis:
> > I don't remember having done this in OSProcessPlugin. I did lots of
> > other horrible things, but I did not pass any C pointers to or from
> > primitives.  Signal handlers, aio event handlers and the like require
> > function pointers, but there is no need pass these pointers to or from
> > the image.
>
> Well here's what I understand by looking at your code. Let's take
> primitiveCreatePipe. It returns an array with two ByteArrays in it that
> contain information about the reader and the writer of the pipe. Let's
> take the first ByteArray, the writer. You create it, take the pointer to
> the bytes and interpret them as a struct of type SQFile. Than you set the
> field "file" inside the struct to the value of writerIOStream which is (on
> unix) a pointer to a FILE structrue optained from a call to fdopen.
>
> writer _ self newSQFileByteArray.
> writerPtr _ self fileValueOf: writer.
> self cCode: 'writerPtr->file = writerIOStream'.
>
> So to me this looks very much like you'r passing pointers to C data
> structures to the image. But I admit that I might still not really
> understand this plugin stuff.

Martin,

Well, in a way you are right. What I am doing here is creating a
ByteArray that will be used as the fileID instance variable of a
StandardFileStream.  The fileID is intended to be treated as an
opaque handle on an operating system file. This handle happens
to be implemented as a copy of the data in a SQFile data structure,
and it includes a pointer to the operating system's file pointer
(either a *FILE or a *HANDLE, depending on the OS). But nothing
on the image side is actually making use of that pointer, it just
happens to be part of the data in the ByteArray that is used as
an opaque handle.

I should note that Andreas has raised an objection to the idea of
creating the fileID outside of the FilePlugin. Strictly speaking,
he's right that it's a Bad Thing To Do, although as a practical
matter it enables me to maintain OSPP and OSProcess independently
of the FilePlugin. I'd like to address this if I could think of
a clean way to do it, but I can't think of any cure that would
not be worse than the disease.

Dave



Reply | Threaded
Open this post in threaded view
|

Re: discuss: [Squeak 0001144]: [ENH] SmartSyntaxInterpreterPlugin

Martin Kuball
Am Sunday, 20. August 2006 16:57 schrieb David T. Lewis:

> On Sun, Aug 20, 2006 at 11:40:44AM +0200, Martin Kuball wrote:
> > Am Sunday, 20. August 2006 00:16 schrieb David T. Lewis:
> > > I don't remember having done this in OSProcessPlugin. I did lots of
> > > other horrible things, but I did not pass any C pointers to or from
> > > primitives.  Signal handlers, aio event handlers and the like
> > > require function pointers, but there is no need pass these pointers
> > > to or from the image.
> >
> > Well here's what I understand by looking at your code. Let's take
> > primitiveCreatePipe. It returns an array with two ByteArrays in it
> > that contain information about the reader and the writer of the pipe.
> > Let's take the first ByteArray, the writer. You create it, take the
> > pointer to the bytes and interpret them as a struct of type SQFile.
> > Than you set the field "file" inside the struct to the value of
> > writerIOStream which is (on unix) a pointer to a FILE structrue
> > optained from a call to fdopen.
> >
> > writer _ self newSQFileByteArray.
> > writerPtr _ self fileValueOf: writer.
> > self cCode: 'writerPtr->file = writerIOStream'.
> >
> > So to me this looks very much like you'r passing pointers to C data
> > structures to the image. But I admit that I might still not really
> > understand this plugin stuff.
>
> Martin,
>
> Well, in a way you are right. What I am doing here is creating a
> ByteArray that will be used as the fileID instance variable of a
> StandardFileStream.  The fileID is intended to be treated as an
> opaque handle on an operating system file. This handle happens
> to be implemented as a copy of the data in a SQFile data structure,
> and it includes a pointer to the operating system's file pointer
> (either a *FILE or a *HANDLE, depending on the OS). But nothing
> on the image side is actually making use of that pointer, it just
> happens to be part of the data in the ByteArray that is used as
> an opaque handle.
>
> I should note that Andreas has raised an objection to the idea of
> creating the fileID outside of the FilePlugin. Strictly speaking,
> he's right that it's a Bad Thing To Do, although as a practical
> matter it enables me to maintain OSPP and OSProcess independently
> of the FilePlugin. I'd like to address this if I could think of
> a clean way to do it, but I can't think of any cure that would
> not be worse than the disease.

I can see the pros and cons. And I have no answer. But at least I get the
feeling that I'm on the right track to understaning the stuff. And my xvid
plugin is coming along very well. This time without using any FFI classes
and
without vmmaker modifications ;).

Martin


Reply | Threaded
Open this post in threaded view
|

Re: discuss: [Squeak 0001144]: [ENH] SmartSyntaxInterpreterPlugin

David T. Lewis
On Sun, Aug 20, 2006 at 09:18:39PM +0200, Martin Kuball wrote:
>  
> I can see the pros and cons. And I have no answer. But at least I get the
> feeling that I'm on the right track to understaning the stuff. And my xvid
> plugin is coming along very well. This time without using any FFI classes
> and without vmmaker modifications ;).

Great, glad to hear it. I don't know much about xvid, but this sounds like
a very worthwhile project.

Dave