re getprogname(): since I don't see man pages in the public case directory,
* is there also a setprogname() as in at least some FreeBSD? If so, is it implicit in the run-time startup, or does one need to call it explicitly? * since argv[0] can be anything, is this equivalent to getexecname() (with the same restriction, i.e. dynamically linked since the info comes from the AUX vector), or does that even matter (since it's new, and new statically linked executables aren't supported anyway)? Actually, I gather that FreeBSD getprogname() ideally returns the last component of the pathname of the executable, whereas getexecname() returns whatever was passed to execve() (and the pr_fname field of /proc/self/psinfo, although the last component, is truncated to PRFNSZ bytes). I imagine a reasonable default would be the last component (or all, if no pathname separators present) of what getexecname() returned, or the same applied to argv[0] if getexecname() could fail (although I'd believe pr_fname before I'd believe argv[0], myself, but getting that is more expensive, and it's truncated). Anyway, if it's a compatibility function, then IMO the behavior should be like that of what it purports to be compatible with. Beware that if you have getprogname(), you may find people wanting the entire FreeBSD err(3) family, not to mention ultimate evil like setproctitle() (which only works with BSD style ps that looks at the current possibly modified process args rather than the cached startup command line). I think my bottom line is that while I'd like to be able to take any code from any Unix-like OS that isn't inherently dependent on kernel specifics, and have great compatibility support for it, I'd like even more to have support for functions in official standards first, in the vain hope that someone actually bothered to write a program to comply with a standard and not just a particular platform; and also that compatibility with anything other than an official (rather than de facto) standard is a balancing act, and perhaps sometimes even a journey that if carried too far, leads to the Dark Side. So...I don't have a problem with de facto compatibility that, even if limited, is non-misleadingly accurate, doesn't break anything, and doesn't interfere with (or detract from the pursuit of) official standards compatibility. -- This message posted from opensolaris.org _______________________________________________ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
