discuss: [Squeak 0001144]: [ENH] SmartSyntaxInterpreterPlugin

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

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

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

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

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