Re: NSProcessInfo.m: Unicode compliance of _gnu_process_args()

[Richard Frith-Macdonald]

On 26 Apr 2006, at 15:36, Roland Schwingel wrote:

> Hi Richard....
>
> > I think not ...
> >
> > The argument/environment strings are, (by definition since they are
> > coming from outside the program), in the external character  
> encoding.
> > The initWithCString: method initialises a string with data in the
> > external character encoding.  The current code should therefore be
> > correct whatever the external encoding is.
> >
> > If you changed the code to use initWithUTF8String: it would be wrong
> > on any system where UTF8 is not used as the external character  
> coding.
> >
> > NB. NSString determines the external character encoding from  
> standard
> > environment variables, and those variable names and values are by
> > definition ASCII, and are accessed via plain C functions and should
> > therefore work irrespective of the external character encoding in  
> use.
> >
> Well...
>
> Imagine you call [NSProcessInfo initializeWithArguments: (char**) 
> argv count: (int)argc environment: (char**)env];
> on either Linux or Windows. In both Operatingsystems you ensure  
> that argv[x] and/or env[x] contains utf8 encoded
> strings. What do you think what happens? The strings are trashed...

Any utf8 strings should only be 'trashed' if your environment does  
not provide the correct encoding information (eg your environment  
encodes data as utf8 but tells the application it's using latin2).

> It can happen that your application runs in an environment where  
> ut8 is uncommon/not set or not the external encoding
> (like on Windows), then NSString would fallback to ISOLatin1 (as  
> far as I remeber) and that would break
> the utf8.

Really no ... if the environment says it's using latin1, and then  
passes utf8, it's the environment which is at fault and needs  
fixing.  The application can't know that external data is being  
passed to it in the wrong encoding.  Changing NSProcessInfo to always  
use utf8 would just break applications in any environment where the  
external encoding is not utf8.

On windows the story is a bit different ... NSProcessInfo should get  
stuff via the wide (UTF16) APIs anyway, and any issues of character  
coding conversion are therefore dealt with within the windows  
libraries/operating-system.

> I wrote because I exactly have these problems frequently. I need to  
> work with files (eg. on my german windows),
> that reside on drives with pathes containing unicode characters.  
> Even I might not be able to display the
> pathes in explorer correctly at any time, I am able to open the  
> files, copy them or whatever I like to do
> when working unicode save, and utf-8 is (mostly) the best way to  
> handle everything between the worlds.

If you are using utf8 for everything, I would expect your locale  
environment settings to say that it is a utf8 environment.
You can always set the GNUSTEP_STRING_ENCODING environment variable  
to 'UTF-8' to override any default system locale info.