[Vm-dev] Adding new primitives to FilePlugin

Eliot Miranda eliot.miranda at gmail.com
Fri Sep 23 17:04:46 UTC 2016


Hi Holger,

On Fri, Sep 23, 2016 at 6:29 AM, Holger Freyther <holger at freyther.de> wrote:

>
>
> > On 23 Sep 2016, at 14:40, David T. Lewis <lewis at mail.msen.com> wrote:
> >
> >
> > I suggest that you try this first by making your own plugin separate
> from FilePlugin.
> > If the idea proves useful in a general way, then consider adding it to
> FilePlugin.
> >
> > FilePlugin is one of a small number of essential plugins that needs to
> be implemented
> > when bringing up a VM an a new platform, so it is generally a good idea
> to resist
> > the temptation to add features there.
>
> Fair enough but the other plugin would need to have access to struct SQFile
> and without plugin dependencies and ABI versioning doing it in another
> plugin
> looks rather fragile.
>
> fdopen is not in C99 but the other primitive does not add burden on
> porting as
> a valid FILE* ptr is passed in and used. No additional API calls are made.
> Any
> objection to this primitive?
>

Not from me.  Seems like a very good idea.  Feel free to contribute an
implementation.

I think we should also provide a primitive that answers the file descriptor
associated with the fileID.  We could also provide primitives that set and
get the FILE * structure if the platform has something analogous.  This
pair of primitives could either fail if the platform fdoesn't use this
(Windows) or degenerate to the file descriptor access primitives.  What do
you think?


>> From your previous email regarding sqFileReadIntoAt(), I think that you
> have
> > already noticed some rather questionable features that have crept into
> this
> > plugin over the years ;-)
>
> yes, the ungetc for stdio seems rather odd.
>
> holger


_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160923/5341fa98/attachment.htm


More information about the Vm-dev mailing list