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

[David T. Lewis]

On Sun, Mar 04, 2018 at 11:26:18AM +0000, Alistair Grant wrote:
>  
> On Sat, Mar 03, 2018 at 03:12:10PM -0500, David T. Lewis wrote:
> >  
> > 
> > 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
> 
> I don't think it is too late.  They only exist in a pre-release version 
> of the Pharo VM, and there's no smalltalk code in the image at the 
> moment to use them.
> 
> 
> > 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?
> 
> That's my understanding, i.e. to allow smalltalk streams to operate on 
> files that have been opened by third-party libraries.
> 
> 
> 
> > 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."
> 
> Yep (mea culpa, this is my comment).
> 
> >   primitiveFileOpenUseFileDescriptor
> > 	"Open the file with the supplied file descriptor and writeFlag.
> > 	fileDescriptor must be an integer.
> > 	writeFlag must be a boolean."
> 
> I agree that based on your description above, it isn't really newly 
> opening a file, however it is calling fdopen(), which does set 
> a precendent.

Yes, I think that fdopen() might be a source of confusion. It is a poor 
function name, since is does not open a file or a file descriptor or anything
else, though at least it does rhymeswith "fopen". But I guess it is probably
too late to complain to the guys who wrote Unix ;-)


> 
> 
> > 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).
> 
> Maybe #primitiveConnectoToFileDescriptor and #primitiveConnectToFile?
> 

Those names sound good to me.

Dave



> 
> 
> 
> Cheers,
> Alistair
> 
> 
> 
> > 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