Le 16/12/2024 à 23:45, Taylor R Campbell a écrit :
PROPOSAL: New libc function
const char *getexecpath(void);
returns the pathname that was passed to execve(2), unmodified.
Thoughts?
Hey Taylor,
I welcome such an addition; I had to deal with a problem alike in a
"portable" way (...), and that ended up in a painful and fragile way. I
have some remarks though, low tier (not blocking/critical).
1 - As there is prior art elsewhere (getexecname(3)), unless there is a
specific (legal?) reason not to have the same name, I would reuse it (or
provide an alias) -- especially when obscure autotooling are looking for
such a function;
2 - some shells like ksh(1) add the "_" environ parameter, and I have
never seen or heard programs behaving badly because of it. So there is
also prior art here -- but that implies a cooperative execve(2) caller,
which is not quite in the present scope. I always wondered whether some
programs used that functionality, but never encountered one (probable
blindness here). Obviously this moves out the functionality from auxv to
envp;
3 - (at least for Linux) /proc/self/file is shown as a symlink, but it
is not really one. When the pointed file is removed (or disappeared,
inaccessible, whatever), AFAIR we get something like "(removed/deleted)"
appended; I expect a symlink to remain as-is. I understand the reason
behind that choice, but it shows the limitations of such an approach,
and how fragile this can become. I became wary of using readlink(2)
results bluntly around /proc and /sys.
DETAILS:
[snip]
Thanks,
--
jym@
