Re: NSString changes

[richard]

On Monday, November 6, 2000, at 06:36 PM, enrico@imago.ro wrote:

> This doesn't solve the problem, (that is bigger and involves also strings 
> used by NSFileManager, NSDirectoryEnumerator, etc...) 
> The text of all the cells of the browser matrices looks something like 
> that: ***t+found, ***e, etc... 
>  
> #0  0x4073a111 in __kill () 
> #1  0x40739d66 in raise (sig=6) at ../sysdeps/posix/raise.c:27 
> #2  0x4073b447 in abort () at ../sysdeps/generic/abort.c:88 
> #3  0x400a1c10 in _NSAppKitUncaughtExceptionHandler (exception=0x83bbe10) 
>     at NSApplication.m:92 
> #4  0x40435e24 in _i_NSException__raise (self=0x83bbe10, _cmd=0x405289f0) 
>     at NSException.m:110 
> #5  0x40435a84 in _c_NSException__raise_format_arguments_ 
> (self=0x40528960, 
>     _cmd=0x405289d8, name=0x817aab8, format=0x40519a70, 
> argList=0xbfffe240) 
>     at NSException.m:75 
> #6  0x404359aa in _c_NSException__raise_format_ (self=0x40528960, 
>     _cmd=0x405194e8, name=0x817aab8, format=0x40519a70) at 
> NSException.m:61 
> #7  0x403cea04 in cString_u (self=0x83212b0) at GSString.m:633 
> #8  0x403ca336 in _i_GSUnicodeString__cString (self=0x83212b0, 
> _cmd=0x40529e20) 
>     at GSString.m:1865 
> #9  0x4043bf74 in _i_NSFileManager__fileSystemRepresentationWithPath_ ( 
>     self=0x8197e18, _cmd=0x40529ef8, path=0x83212b0) at 
> NSFileManager.m:1262 
> #10 0x4043c80c in _i_NSDirectoryEnumerator__findNextFile (self=0x8388268, 
>     _cmd=0x40529fc0) at NSFileManager.m:1365 
> #11 0x4043cfd0 in _i_NSDirectoryEnumerator__nextObject (self=0x8388268, 
>     _cmd=0x40529d78) at NSFileManager.m:1470 
> #12 0x4043ba0d in _i_NSFileManager__directoryContentsAtPath_ 
> (self=0x8197e18, 
>     _cmd=0x80ec518, path=0x8388240) at NSFileManager.m:1150 
> #13 0x8060cf9 in _i_Viewer__browser_createRowsForColumn_inMatrix_ ( 
>     self=0x8306c28, _cmd=0x4026bb10, sender=0x8381a70, column=1, 
>     matrix=0x8387e58) at Viewer.m:546 
> #14 0x400c7e3e in _i_NSBrowser_Private__performLoadOfColumn_ 
> (self=0x8381a70, 
>     _cmd=0x4026b628, column=1) at NSBrowser.m:2896 


Hmm ... I guess there must be some other bug then ...
I think you need to run under gdb and go back up a few stackframes after the 
crash
and see what the cString_u function thinks the current default cString encoding 
is.
This should only be happening if the strings you are using (in this case 
filenames)
contain characters that can't be represented in the current encoding - but it 
may be
that either there is some bug that is stopping the encoding being set 
correctly, or
there is a bug in the unicode->cString conversion.  I don't think I can tell 
unless
you can give me some way to replicate your setup perfectly, and run under gdb 
myself.