[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
|