|
Message-ID: <20130324001618.GA4844@brightrain.aerifal.cx> 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.