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...
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.
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.
It might also happen that my app (containing ALL libraries) is in an unicode path, so I wrote especially because of that,
because than the NSProcessInfo thingy comes to live for me...
Roland
_______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
