[Vm-dev] VM Maker: VMMaker.oscog-akg.2340.mcz

[David T. Lewis]

On Sat, Mar 03, 2018 at 12:42:02PM -0500, David T. Lewis wrote:
>  
> On Sat, Mar 03, 2018 at 11:43:01AM -0500, David T. Lewis wrote:
> >  
> > On Sat, Mar 03, 2018 at 04:50:40PM +0100, Levente Uzonyi wrote:
> > > 
> > > On Sat, 3 Mar 2018, Holger Freyther wrote:
> > > 
> > > >
> > > >
> > > >
> > > >>On 3. Mar 2018, at 15:08, Levente Uzonyi <leves at caesar.elte.hu> wrote:
> > > >>
> > > >
> > > >Hey!
> > > >
> > > >
> > > >>>Squeak devs opposed this so we are guarding it with PharoVM.
> > > >>
> > > >>Can you point me to the discussion?
> > > >
> > > >Sure. It is my thread from 2016. 
> > > >http://forum.world.st/Adding-new-primitives-to-FilePlugin-td4916711.html
> > > 
> > > Maybe it's just me, but I don't see any opposition in that thread.
> > > 
> > > Levente
> > >
> > 
> > For my part, I was recommending a way to proceed, that's all.
> > 
> > Regarding the "#if PharoVM", I don't see a need for this. After all, people
> > who do not want to use a primitive are free to not use it.
> > 
> > I do think that a working implementation should be provided for Windows.
> > A Windows HANDLE is roughly equivalent to a Unix file descriptor, and the
> > *file element of SQFile is a HANDLE, so I expect that the implementation
> > should be trivial.
> > 
> 
> I should have looked at the code before replying. The Windows implementation
> would be trivial, but it does not make any sense.
> 
> Sorry for the noise,
> Dave
>

Is it too late to ask about the names of these primitives? I'm not sure that
I understand the use case, but I am looking at the discussion referenced earlier:
  http://forum.world.st/Adding-new-primitives-to-FilePlugin-td4916711.html

>From this I would assume that the intended usage is to get a previously opened
file descriptor or a previously opened *FILE pointer by means of some FFI call,
then pass this to one of the two new primitives in order to build a SQFile data
structure that is returned to the image in the form of a ByteArray. Presumably
the ByteArray would then be used to set the fileID field of a file stream (but
I am not clear on whether that is the intent).

If I am reading the code correctly, that is exactly what the two primitives do.
Is that right?

The names and comments say that the primitives are actually opening the files,
which appears not to be the case.

  primitiveFileOpenUseFile
	"Open the file with the supplied FILE* and writeFlag.
	FILE* must be supplied in a byte object (ByteArray) with the platform address size.
	writeFlag must be a boolean."

  primitiveFileOpenUseFileDescriptor
	"Open the file with the supplied file descriptor and writeFlag.
	fileDescriptor must be an integer.
	writeFlag must be a boolean."

I'm not sure I can think of any good names off the top of my head, but if
the above is right, and given that the ByteArray returned by the primitive
corresponds to the fileID field in a FileStream, then maybe it would be something
like #primitiveFileIDBytesFromFD (for the integer file descriptor or Windows
integer HANDLE) and #primitiveFileIDBytesFromStdioStream (for a *FILE).

It actually does look like the primitive that uses integer file descriptor
would be appropriate for Windows, so that probably can be implemented.
On Windows, you would still need some way to deal with the file handle registry
in FilePlugin, because Andreas was rather strenuously opposed to people (such
as for example me!) doing things in the FilePlugin with file handles that did
not actually originate from the plugin. He was trying to find a more general
solution to this for security reasons, although we never actually implemented
any solution and the handle registry is probably still in effect on Windows.

Please don't take this as objections, I'm just trying to understand the intent
and maybe suggest better naming or comments in the primitives.

Dave