Dave Love wrote on 2006-01-04:
> Gnulib routines call `error', and on a non-glibc system that's likely
> to use an uninitialized `program_name' since the variable is
> initialized in progname.c, and that's not required. Users probably
> won't find out about it until `error' gets called at some stage and
> prints junk; ...
It is regrettable that newbie users of gnulib will get a core dump the
first time error() is called. But there's no way out except to document it,
because it is a consequence of
- the fact that on Unix, you don't have access to argv[0] except from
within main(),
- we _do_ want error messages to be generally prefixed by the program name.
> Shouldn't `program_name' be initialized in error.c instead (perhaps to
> a more meaningful value than NULL)?
If you do this, you spare the developer a one-time core dump and one line
of code. But the user will not know which programs prints a particular
error message. Which leads to decreased transparency of the system.
(I'm glad on Linux most error messages identify their originator.
Transparency is one of the major features of Linux compared to proprietary
OSes.)
> It could probably do with a note about this in gnulib.texi, but I
> don't know whether the variable is meant to be set directly or only
> through `set_program_name'.
Yes such a piece of doc is welcome. The advice is simple:
- If the gnulib module 'progname' is in use,
set_program_name (argv[0]);
should be called in main().
- Otherwise the program should define program_name itself:
const char *program_name;
and initialize it in main():
program_name = argv[0];
> if gnulib supports a library, that can't ensure it's set anyway.
Using error() inside an exported, documented library is a bad idea anyway,
because error() can call exit(1), and most programs aren't prepared for
library calls that cause a program termination.
Bruno
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
