kernel32: Overhaul the handling of argv in set_process_name().

[Ken Thomases]

On Jul 12, 2016, at 2:45 PM, Sebastian Lackner <sebastian at fds-team.de> wrote:
> 
> On 12.07.2016 06:44, Ken Thomases wrote:
>> This fixes several problems with the code:
>> 
>> * The code had been assuming that the argument strings pointed to by the argv
>>  array are contiguous iff certain process-name-setting functions are available.
>>  This doesn't seem reliable.  Instead, test if it's true and shift the strings
>>  if so.
> 
> Thanks for working on this, looks indeed like a nice improvement.

You're welcome and thanks. :)


>>  However, setproctitle() is specifically documented as a preferred alternative
>>  to the technique of overwriting the arg strings, so don't shift the strings
>>  if that's available.
> 
> Wouldn't it make sense to remove the directory component also in this case, to
> be consistent? By moving the code to the bottom all functions would be called
> in the same way.

Well, the only reason we remove the directory component for the other calls is because they only allow limited storage.  I'm not aware of a similar limit for setproctitle().

Also, setproctitle() is theoretically more similar to the shifting of the argument strings than to setprogname() or prctl(PR_SET_NAME).  And we don't make any attempt to remove the directory component for the string shifting.  (I.e. "ps" will show the full command line, potentially including Windows-style .exe path.)

Moving the code to the bottom could be done, although it would mean two #ifdef HAVE_SETPROCTITLE blocks, one to set shift_strings and the other to actually make the call.  The reason is that the shifting has to happen before the call to setprogname() because it's documented to keep the pointer that's passed in.  We can't pass it (a substring of) argv[1] and then shift the strings.

-Ken