[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sat, 23 Mar 2013 20:16:18 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: program_invocation_name
Hi,
I've seen some demand again for the GNU extension
program_invocation_name (and program_invocation_short_name) and I'm
not totally opposed to adding them (although the latter adds some ugly
nontrivial startup cost), but I'm also frustrated that they're not
documented properly. The glibc manual defines them as:
— Variable: char * program_invocation_name
This variable's value is the name that was used to invoke the program
running in the current process. It is the same as argv[0]. Note that
this is not necessarily a useful file name; often it contains no
directory names. See Program Arguments.
— Variable: char * program_invocation_short_name
This variable's value is the name that was used to invoke the program
running in the current process, with directory names removed. (That is
to say, it is the same as program_invocation_name minus everything up
to the last slash, if any.)
But my understanding is that these descriptions are false, and that
program_invocation_name is just a pointer to the same storage as
argv[0], and program_invocation_short_name points to the tail of
argv[0]. In this case, modifications to argv[0] would be reflected
through these pointers. Is that correct and reasonable? The
alternative, copying a string that could be up to ARG_MAX to its own
storage, is obviously nasty and unwanted.
If we do add program_invocation_short_name, what should the size/speed
tradeoff be? I really don't want to make strrchr a mandatory part of
the startup code; would a trivial loop to do the job suffice?
for (s=t=argv[0]; *t; t++) if (*t=='/') s=t+1;
Rich
P.S. If we do add these, we could certainly add the BSD names too as
aliases.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
