gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch for unicode support on Win32 in GNUstep base


From: Richard Frith-Macdonald
Subject: Re: Patch for unicode support on Win32 in GNUstep base
Date: Wed, 25 Aug 2004 09:41:29 +0100


On 24 Aug 2004, at 04:41, Adam Fedor wrote:


On Aug 4, 2004, at 5:14 AM, Roland Schwingel wrote:
 Well... The reason for adding the additional 'w' method for
fileSystemRepresentationWithPath: is that fileSystemRepresentationWithPath: is defined to return const char* in the OpenStep spec. If your path contains unicode chars you cannot convert them to const char*. You need to convert
 them to const unichar* to be later on able to work with it.

Having just one method (fileSystemRepresentationWithPath:)would mean to
 change it to return either const unichar* instead of const char* or
 NSString. Both would break the OpenStep spec and compatibililty.

So we introduced (yet only internally used in GNUstep base and only for
 windows)
wFileSystemRepresentation: to be able to handle paths containing unicode
 characters
 on windows.


I can see the logic of adding another method. Although it may be possible to cast back and forth from (unichar *) to (char *), it isn't good programming practice, and not very intuitive either (how does a developer know which format -fileSystemRepresentation is in, except perhaps for the documentation and checking which OS you are on).

Still, you state that it is only used internally in base (perhaps it should be in a private header?) but should we restrict developers from using themselves if they want?

Any other opinions?

My feeling is that, if the filesystem names are going to be unicode (ie contain characters which can't be represented in any one single byte characterset), the encoding should be utf-8 and so -fileSystemRepresentation would return a utf-8 sequence, which could then be converted to 16-bit unicode if/when it is passed to a system call.

The only problem with that is ... what if people set their default encoding to be (for instance) latin1, but they try to use filenames containing characters which can't be represented in that characterset and need utf-8? I think this could be a problem on any system though, not just windows.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]