Subject: getprogname() & setprogname() (killing __progname usage)
To: None <email@example.com>
From: Chris G. Demetriou <firstname.lastname@example.org>
Date: 02/16/2001 18:30:29
Following up on previous discussions in the last half year or so, i've
come up with a (substantial) diff to implement getprogname() and
setprogname() and actually use the former in many places in the source
tree. (i actually did it in 1.5, so new things would be missed. And
I didn't touch crypto or any of the 'dist' trees.)
I'm not at this time going to start to go through and try to make
everything use setprogname(). It's not necessary, it would take a lot
of time, and except in a few specific cases it wouldn't make my life
any better. People can do it as they touch sources for other reasons,
or if somebody wants to go on a crusade, good for them.
Anyway, below i've included the manual page for getprogname() and
setprogname(). I'm planning to commit it soon.
Rationale for various features, based on previous discussions & my own
* It's not portable to modify the actual arg strings passed to the
program. Therefore, portable programs (i.e. the targets of this
interface 8-) will keep them constant, so the argv contents are
fine to use throughout the life of the program. (This also matches
existing NetBSD behaviour).
* The program name as presented to the user should _not_ be randomly
resettable. In error messages, they should be presented using the
name that they used to invoke the program (i.e., derived from
argv). Given that, there's no reason to change it if it's
already set. Given _that_, there's no reason to do much extra work
at startup on NetBSD (e.g. another set of strrchr, etc. calls) to
set the program name.
* Following from the previous point, getprogname() will return a
"consistent enough" value over the life of the program that it can
be marked const (allowing CSE, etc.), so it's not necessarily
significantly more expensive to use than if it expanded into a
variable reference, even if you're gonna use it Lots of times.
* As you might gather from the above, both getprogname() and
setprogname() expand into function calls, rather than macros. The
notion being, if we want to change the implementation at some point
in the future, we can do so more easily that way.
Anyway, if you have issues with the above, speak now... If you're
going to argue that one of the above is a bad decision, please try to
do so with some kind of coherent argument about why what's mentioned
above is wrong.
Chris Demetriou - email@example.com - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.
GETPROGNAME(3) NetBSD Programmer's Manual GETPROGNAME(3)
getprogname, setprogname - get/set the name of the current program
Standard C Library (libc, -lc)
const char *
setprogname(const char *name);
These utility functions get and set the current program's name as used by
various error-reporting functions.
getprogname() returns the name of the current program. This function is
typically useful when generating error messages or other diagnostic out-
setprogname() sets the name of the current program to be the last path-
name component of the name argument. It should be invoked at the start
of the program, using the argv passed into the program's main() func-
tion. A pointer into the string pointed to by the name argument is kept
as the program name. Therefore, the string pointed to by name should not
be modified during the rest of the program's operation.
A program's name can only be set once, and in NetBSD that is actually
done by program start-up code that is run before main() is called.
Therefore, in NetBSD, calling setprogname() from main() has no effect.
However, it does serve to increase the portability of the program: on
other operating systems, getprogname() and setprogname() may be imple-
mented by a portability library, and a call to setprogname() allows that
library to know the program name without modifications to that system's
program start-up code.
The getprogname and setprogname function calls appeared in NetBSD 1.6.
NetBSD 1.5 February 11, 2001 1