On Jul 12, 2016, at 2:45 PM, Sebastian Lackner sebastian@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