On 26-Mar-06, at 4:35 PM, Andreas Raab wrote:
John M McIntosh wrote:
The mpeg plugin uses it to take the file name and to open it, also the freetype 2 plugin where it's the path to the font file.
Not in any version of the MPEG plugin that I have. Which reminds me: Did you see my message about the linker error due to the undefined reference to "sqFilenameFromStringOpen"? Could this be related?
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); }
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.
Then pass in the translated results, however now it's an issue of backward/forward compatibility.
Usage of it in the standard unix based VMs can be seen in the Cross/sqFilePluginBasicPrims.c /* copy the file name into a null-terminated C string */ if (sqFileNameSize > 1000) { return interpreterProxy->success(false); } interpreterProxy->ioFilenamefromStringofLengthresolveAliases (cFileName, sqFileName, sqFileNameSize, true);
I see. If the other usages are the same then the one thing that's missing from my implementation is a terminating zero character, yes?
Yes
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.
Cheers,
- Andreas
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===