[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fileSystemRepresentationWithPath:
From: |
Richard Frith-Macdonald |
Subject: |
Re: fileSystemRepresentationWithPath: |
Date: |
Fri, 08 Jul 2005 13:01:50 +0100 |
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.