Dave Love <[EMAIL PROTECTED]> writes: > Paul Eggert <[EMAIL PROTECTED]> writes: > >> Under the current approach, it's the caller's responsibility to arrange >> for a program_name variable that works, either by using the progname >> module, or by rolling their own program_name variable. > > So gnulib shouldn't be used for libraries (or at least not unless you > avoid modules calling `error' or accept errors spewing junk messages)?
It is a problem, yes. However, it's not quite as bad as that. The library can arrange for program_name to be initialized before it is used. >> I suppose it might make sense for error.c to avoid using program_name >> if it's null. > > That's probably a good idea, but why can't it be initialized to null > in error.c? Because the current convention is to put this declaration in the main program, at the top level: char *program_name; Hence the main program has allocated program_name, and has arranged for it to be initialized to null. If we put a similar declaration in error.c, it would cause two different definitions of program_name, and some non-Unix linkers reject this. (The C Standard allows them to reject it.) > (If the interface to it was just set_program_name, it could be private.) Yes, that would be a better convention. This will require revamping pretty much everybody that uses program_name, but I think it's worth the pain. What do others think? _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
