John M McIntosh wrote:
The mpeg plugin uses sqFilenameFromStringOpen()
which I declare as
#include "sqVirtualMachine.h"
extern struct VirtualMachine * interpreterProxy;
void sqFilenameFromStringOpen(char *buffer,long fileIndex, long fileLength, int flag) { interpreterProxy->ioFilenamefromStringofLengthresolveAliases(buffer,fileIndex, fileLength, flag); }
So where is this declaration? I can't find it anywhere.
The api then converts the given file name in VM platform character type (macroman/utf-8/latin-1) into a string that the host operating system can use to act upon using host operating system file calls.
Which, again, makes me want to ask why we actually burden the plugin with figuring that out instead of giving it a filename that works?
Well we need a primitive that would translate the image file string to the host api file name. ioFilenamefromStringofLengthresolveAliases comes to mind.
Well, my point is that if we expose that primitive to the image, we will never have the need to do it from a plugin because you can always pass a valid file name into it. It's really strange to me that the VM does translation for stuff which is (supposedly) handled in the image already. I could understand this if we would shoot for a file/directory abstraction inside the image but the way it's right now we're hiding stuff from the image that the image supposedly is responsible for (platform file name handling) and that's Just Wrong (tm).
And like David mentioned, the above is prone to buffer overflow attacks whenever the VMs encoding is larger than the image's (which is easily possible if you consider, e.g., latin1 -> utf8 conversion).
Ya, likely we should pass in the max size of the target buffer.
Why not just return "char*" and let the implementor figure out the size of the buffer? On most systems that size is bounded (by MAX_PATH or similar) which means that a "static char[MAX_PATH]" does the job just fine on the implementors side.
Cheers, - Andreas