Hello Bastien,
> We could at least in all the case implement getprogname/setprogname
> what is a well known api
We can implement something _similar_ to getprogname. But it won't be
the same API, because
- our function can return NULL,
- our function can return a truncated value,
- there will be no function that corresponds to setprogname(),
because the point of this exercise is to avoid the 'progname' module.
> and in gnulib error use the maximal
> information possible to get full program name.
This would mean that the error message from error() looks different
according to the OS:
- no directory shown on *BSD, HP-UX, IRIX, OSF/1,
- sometimes a directory shown on AIX,
- an absolute but uncanonicalized directory shown on MacOS X,
- a resolved but uncanonicalized directory shown on Solaris,
- a canonicalized directory shown on Linux, Cygwin, mingw.
Do you imagine the troubles that testsuite writers will have when writing
unit tests that check error messages? It's already bad enough currently,
where mingw behaves differently than all other platforms. 2 cases to be
handled. But 5 different cases - that is madness.
> Or better, in a lot of system when the library is loaded you could run
> some kind of constructor/init code; and thus save current dir at
> initial time and current $PATH.
That would not be "better": Recall that the system calls that retrieve
process information are quite expensive (I think they need the Big Kernel
Lock on many platforms). Therefore I would find it mandatory that this
information is only fetched when needed and does not increase the program
startup time.
> using a c++ code snipped is the most easy way to do that. Using a
> constructor of a static object for instance.
But we don't want to link libposix against libstdc++. For reasons of
program startup time, again.
Bruno
