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

[David Ayers]

Roland Schwingel schrieb:

> 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...

Hello Roland,

How can you reliably insure that argv/env contain UTF-8 in the common
case?  Are you using wrapper scripts to manipulate the environment?

On POSIX systems the environment variables LANG/LC_* associated with the
locale are the indicators of what character set (NSStringEncoding) to
expect for any external source.  Now I can very well imagine that
GNUstep's current machinery may need to take extra steps in determining
the correct locale under windows and I'm not sure if/how we can use
libiconv on mingw.  But wrapping the executable in scripts or other
executables that manipulate the character set of the environment
variables and doesn't set the corresponding locale seems like the wrong
approach.

> 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.

Determining the character set has well defined methods (at least for
POSIX systems and I'm sure windows also has some way).  Also all UTF-8
character sequences are also valid ISOLatin1 and what makes ISOLatin1
more special than ISOLatin2 or even ISOLatin9 if you want the euro sign?

> 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...

OK, so we have a bug.  Let's figure out the correct way to determine the
locale on windows and except the the environment variables to be in that
encoding.

Now I believe the that file accessing API already uses the mingw API
which I believe expects UTF16 (close, but not really Unicode so there
might be some issues) character set so once you have the correct
NSString in the application you should be able to access the files already.

Could some windows guru weigh in on this?

Cheers,
David