[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