[BUG] Can't write files with Squeak 3.2.7Beta5 on MacOS X 10.1.2

John M McIntosh johnmci at smalltalkconsulting.com
Mon May 27 05:43:35 UTC 2002


>This is a resend, this time with the promised attachment!
>
>________________
>
>At 17:08 -0700 05/22/2002, John M McIntosh wrote:
>
>>having a repeatable test case would be nice.
>>
>
>Please try the attached SUnit tests.  When I run them on Squeak 
>3.2.7Beta5 they fail, but on Squeak 3.0Alpha21MTCarbon they pass. 
>This is using the same image in both cases.

Well if you pass ascii > 127 to unix systems for characters in path 
names I'm not sure what the behavior should be. However a 
misunderstanding of how the ascii to unicode translations should go 
defeats this in the current Mac VMs.

I ask for
filePath   = CFStringCreateWithBytes(kCFAllocatorDefault,
                     (UInt8 
*)pathString,pathStringLength,kCFStringEncodingMacRoman,false);

where pathString contains ascii 196.  But the resulting unicode 
CFString has ascii 192! MMm but later after ensuring all the path is 
correct and aliases resolved we convert to an ascii string using 
MacRoman and we get

"/Users/johnmci/Documents/Squeak3.2.7osx/build/check\304/TestFile0"

8r304 -> 196 base 10

That calls fopen which fails the open because of the 8r304

Ah, but it seems I need to lie here. Instead of converting to 
MacRoman I need to convert to kCFStringEncodingUTF8 which then allows 
me to fool with the unicode aware file system yet use an ascii 
representation for the fopen

This of course isn't an issue with 3.0 because we deal with a 
different execution path and the old apis which allow ascii 196.

So I'll look into fixing in the next revision

-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================



More information about the Squeak-dev mailing list