InterpreterProxy>>ioFilename:fromString:ofLength:resolveAliases:?

John M McIntosh johnmci at smalltalkconsulting.com
Mon Mar 27 04:06:14 UTC 2006


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 at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===




More information about the Vm-dev mailing list