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

[David T. Lewis]

On Sun, Mar 26, 2006 at 11:35:35AM +0200, Bert Freudenberg wrote:
> Am 26.03.2006 um 09:11 schrieb Andreas Raab:
> > tim Rowledge wrote:
> >> On 25-Mar-06, at 10:33 PM, Andreas Raab wrote:
> >>> This function is news to me - can somebody explain what it's good  
> >>> for, where it should be used and (most importantly) why we'd  
> >>> export this for plugins but don't use in the VM itself (e.g., no  
> >>> senders)?
> >> See mantis 2044 for some details and the original rationale. It  
> >> also relates somewhat to :-
> >
> > I guess you mean http://bugs.impara.de/view.php?id=2404 yes? One  
> > question about this: Do we have a way of doing that kind of file  
> > name conversion from the image itself? It strikes me as somewhat  
> > odd that a plugin needs to do that conversion given that the image  
> > can just pass a well-formed version of the string as the argument, no?
> 
> Not if the VM creates the illusion of some other naming than the  
> actual system uses. Like the use of HFS file names in the Mac VM  
> (with : separators), where the VM translates to unix path names  
> nowadays. The problem with the macro was that it called (on the Mac  
> at least) a non-exported VM function. But in the freetype plugin I  
> needed to be able to convert from the path name the image uses to the  
> actual system path name. So just using the macro didn't work, which  
> is why we added that function.

This is as good a time as any to mention that there is a potential for
buffer overrun problems in ioFileName:fromString:ofLength:resolveAliases.
By definition, the sender does not know what the file name will be translated
to, hence cannot know how large the pre-allocated aCharBuffer should be.

The sender in this case may be any arbitrary primitive written by some
clueless twit such as myself. That means that sqGetFilenameFromString()
needs to protect against buffer overruns.

Dave