NSProcessInfo.m: Problem with **LONG** commandline on linux

[Roland Schwingel]

Hi...

Last night I ran into a problem with NSProcessInfo.m (from 1.7.2) on 
linux which caused GNUstep to crash... It happened to me to get a 4561 
Bytes long commandline to run a tool (toolname + 43 Arguments)... Ok I 
know this isnt very common but maybe NSProcessInfo shouldn't crash 
handling it. What exactly happens is still a bit mysterious... But when 
entering _gnu_process_args() (called by +[NSProcessInfo initialize] 
there is at present a check

 if (argv != 0)
   {
         _gnu_arg_zero = (char*)malloc(strlen(argv[0]) + 1);
         strcpy(_gnu_arg_zero, argv[0]);
   }
 else
  ....

Well in my case argv was a pointer but argv[0] was NULL, so strlen() 
crashes...I changed it to look that way

 if (argv != 0)
   {
       if (argv[0] != NULL)
       {
         _gnu_arg_zero = (char*)malloc(strlen(argv[0]) + 1);
         strcpy(_gnu_arg_zero, argv[0]);
     }
   }
 else
  ....

Afterwards everything runs fine (for my tool, because it handles 
argv,argc directly in main() where argv and argc are correct, not 
needing NSProcessInfo for it)... So adding this check here might not be 
that wrong, but the real reason for being _gnu_noobjc_argc, 
_gnu_noobjc_argv bogus (set in +load from procfs) has to be 
invesitigated to get it really working with linux as well...  I can 
reproduce this everytime. The commandline needn't be exactly that size 
can also be smaller for the bug to appear on my side (SUSE 8.0, kernel 
2.4.20, glibc 2.2.5,gnustep-base 1.7.2.,gnustep-objc 1.3.0,gcc 3.2.2)

Maybe adding at least this tiny if(argv[0] != NULL) can IMHO not harm....

Roland