woods@weird.com (Greg A. Woods) writes:
> Is this a good/necessary idea?  I'd rather be able to reset the value.

I'd rather you not.  This is supposed to be the name of the program as
invoked by the user.  That doesn't change.


> Style-wise I personally would just use this much more concise statement:
> 
> 	__progname = basename(arg0);	/* a SUSv2 compatible function */

I didn't know about that one.  "heh."

In fact, on NetBSD, since this is set up via crt0 anyway, to my mind
setprogname() would actually end up being a no-op on netbsd.


> I'm not terribly comfortable at modifying argv[0] though, at least not
> in this kind of context (nor about basename doing this either, though
> when I do the equivalent in my own programs I don't worry about whacking
> it).

uh, neither modify argv[0].  (or at least, the code that i provided
didn't, and I don't think basename should...  if it does, it's
implemented ... interestingly.)

In general, as far as i'm concerned, modifying argv in general is a
bad idea.  if a program Really Really Really Really wants to change
how its arguments are seen by e.g. ps, it should use setproctitle.


> Of course err() and friends are a bit of a pain for porting too -- I'd
> much rather NetBSD source stick to POSIX/SUSv2 stuff internally too.
> Yes it's possible to cart off some of these functions and make a
> lib44bsd or similar but it's a bit of a pain; and at least for err() and
> friends it's not really all that much harder to write code using
> standard portable functionality that's much clearer for any outsider to
> read....

Right, so then the problem becomes "every program and its cousin
define a function do print an error message an exit, each slightly
different, half slightly wrong."

It's not particularly hard to create such a portability library, and
it's actually not too large.  it really depends on what you're trying
to port.

the things that annoy me are:

* places where you've got programs including other programs source
files via path tricks.  Great, one less copy in the source tree, but
that can be a bit of maintenance hair if you're porting things to
other systems...

* the huge amount of deviation that has to be worked around in N
places, e.g. inclusion of sys/cdefs.h at the top of every file, use of
__P in user programs, use of non-standard header files, etc.  You can
for the most part work around these by defining a "compatiblity"
header, then going through and #if'ing out all of the non-standard
#includes... but some are more annoying (e.g. the __COPYRIGHT etc.,
stuff from cdefs.h -- you can't sanely include a general compat header
at the top of the src file so then you need two...), and even though
each may be individually easy, you tend to have to touch N lines of
code in each file.  yuck.



cgd