Re: [bug #15353] win32 compilation of base fails on NSProcessInfo.m (checked out from CVS today)

[Richard Frith-Macdonald]

On 9 Jan 2006, at 05:27, Sheldon Gill wrote:

> > Follow-up Comment #5:
> > I'm fairly sure this is fixed by moving the declaration of
> > fallbackInitialisation.
> > At least ... the current code in CVS compiled and runs fine for me
>
>
> Could you please explain why "fallbackInitialisation" is needed and  
> a good idea?

I'm not at all sure it *is* a good idea.

Basically, it arises from a complaint I got from a windows user  
(can't remember who) when I fixed the NSProcessInfo code for  
obtaining the environment information to ensure that it got the  
correct character encoding (using the unicode api ... the original  
code just assumed that the environment info was in latin1 encoding).

The change broke this persons code ... he was using  
+initializeWithArguments:count:environment: to specify an environment  
to which he had added some extra environment variables, and my  
restructuring with fallbackInitialisation was a quick hack to restore  
the original behavior where the real environment can be overridden.

Now, the intention of +initializeWithArguments:count:environment: was  
to supply a mechanism to initialise NSProcessInfo for  systems where  
the base library can't determine args/env automatically, not to  
override/alter the args/env, so arguably he shouldn't have been using  
it for that, which is why I'm not sure that continueing to support  
that behavior is a good idea.

If we *do* want to allow the args/env to be overridden  
programmatically, we should document the behavior and ensure that it  
always works.