On Mon, Jan 09, 2006 at 02:49:45PM +0100, Bruno Haible wrote:
> And how about a runtime failure that occurs in every invocation? We
> could add a check in getopt() and getopt_long(), verifying that
> program_name is non-NULL. Most GNU programs use getopt() and
> getopt_long().
I like the principl
Paul Eggert wrote on 2006-01-05:
> > (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?
GNU gett
James Youngman wrote on 2006-01-05:
> My problem is that we have changed the interface without making it
> impossible for the user to use the new interface wrongly. I would
> prefer an arrangement which results in a compilation or link failure
> if the user (i.e. software maintainer) fails to init
Dave Love wrote on 2006-01-05:
> why can't it be initialized to null in error.c?
There are other modules using program_name than error.c. For example,
argmatch, argp-help and xerror. Consequently,
- If you have an application that uses 'argp' but not 'error',
program_name would not be define
Paul Eggert wrote on 2006-01-06:
> Perhaps we could change progname.h so that 'program_name' is a
> function that returns the program name, instead of being a global
> variable.
Ouch. When things go wrong, this leads to intriguing compiler errors like
"cannot call program_name as a function" or "a
Karl Berry wrote on 2006-01-05:
> Is it a problem in practice, ie, what are these non-Unix linkers?
MacOS X (a Unix!), Woe32, emx+gcc (a Unix as well). Maybe others.
> Are you thinking that set_program_name will set something other than
> program_name?
It already does. See progname.c.
Bruno
