Re: fileSystemRepresentationWithPath:

[Richard Frith-Macdonald]

On 2005-07-08 12:02:45 +0100 Leigh Smith <address@hidden> wrote:

> > Digging deeper, the problem reduces to that NSFileManager - 
> fileSystemRepresentationWithPath: is defined to return a unicode  encoded 
> const char * string, whereas NSBundle -load NSDebugFLLog()  statements are 
> assuming the string returned from  fileSystemRepresentationWithPath: is an 
> 8 
> bit char *, not unicode.

Thanks ... the debug logging needs to be fixed for windows then.  I'll try 
to do that.

> The __objc_dynamic_link() definition in 
> win32-load.h calls  LoadLibraryExW() which assumes (casts) it's filename 
> parameter is  unichar *.
>
> The problem seems to be that the string returned by 
> fileSystemRepresentationWithPath: does not have the leading '\0' for  latin 
> unicode, but subsequent characters do have the leading '\0'  hence the 'c' 
> alone being displayed by the NSBundle debugging code  (which prints using 
> %s).

I *think* that's correct ... shouldn't the nul byte appear second because 
intel uses little-endian byte order.

<snip>

> My point being the lack of byteOrderMark, or a leading '\0' in the  string, 
> unless there is strange behaviour treating unichar * strings  and casting 
> them back to char *.
>
> I'll dig in further.

My understanding is that windows does not expect to find a BOM in strings 
passed to its wide API.

I wonder ... are you still using the old narrow character API when loading?
I think perhaps you need to rerun configure to get the correct version of 
the file in place.