[Top][All Lists]

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

Re: Patch for unicode support on Win32 in GNUstep base

From: Sungjin Chun
Subject: Re: Patch for unicode support on Win32 in GNUstep base
Date: Wed, 4 Aug 2004 23:33:18 +0900


As far as I know, if we use UTF-8, then it could be represented as const char *, isn't it? Does windows uses UTF-16 for representation? I'm using Korean version of Windows but I do not have problem with char * for file name representation if I use UTF-8 encoding.
But this is not proved :-)

On Aug 4, 2004, at 8:14 PM, Roland Schwingel wrote:


Alexander Malmberg wrote:
> The current methods for converting paths to/from the fs representation
> are supposed to convert to whatever the system wants, so if the wide
> character strings are what the system wants, that's what they should
> convert to/from (and if this breaks other methods that assume that the
> fs representation can be used as a c string, those methods should be
> fixed).
> Adding a second set of methods for a specific system seems wrong, and
> goes against the entire purpose of hiding the conversions behind a
> single, cross-platform interface. Why not fix the first set?

I think you are talking about fileSystemRepresentationWithPath: and

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.


Discuss-gnustep mailing list

reply via email to

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