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

Alistair Grant akgrant0710 at gmail.com
Sun Mar 4 11:26:18 UTC 2018


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.


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




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


More information about the Vm-dev mailing list