[ This is http://article.gmane.org/gmane.comp.lib.gnulib.bugs/5080
Please remove bug-gnulib from followups. Thank you. ]
* Paul Eggert wrote on Fri, Jan 06, 2006 at 12:06:59AM CET:
> [EMAIL PROTECTED] (Karl Berry) writes:
>
> > Is it a problem in practice, ie, what are these non-Unix linkers?
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
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 sta
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
Paul Eggert <[EMAIL PROTECTED]> wrote:
> > -# define program_name program_invocation_name
>
> Let's omit this '#define', and change all uses of program_name to
> program_name in the rest of the code. The other arm of the #if can
> then contain
>
> #define program_invocation_name program_name ()
Thanks for taking this on.
James Youngman <[EMAIL PROTECTED]> writes:
> --- doc/standards.texi25 Dec 2005 23:59:50 - 1.10
> +++ doc/standards.texi6 Jan 2006 11:35:14 -
This part we should funnel through the standards maintainer. There
shouldn't be any problem with i
* doc/standards.texi: Modify examples to show the new usage pattern
for program_name.
1) The fact that this is ensconced in the coding standards makes me
worry more than ever about compatibility. For one thing, why define the
same symbol program_name as a new, incompatib
On Thu, Jan 05, 2006 at 03:06:59PM -0800, Paul Eggert wrote:
> [EMAIL PROTECTED] (James Youngman) writes:
>
> > I would prefer an arrangement which results in a compilation or link
> > failure if the user (i.e. software maintainer) fails to initialise
> > things properly.
>
> Perhaps we could ch
Paul Eggert <[EMAIL PROTECTED]> writes:
> Perhaps we could change progname.h so that 'program_name' is a
> function that returns the program name, instead of being a global
> variable.
If it's any help, I can tell you what libroken does; I suspect it's
emulating a BSD facility. (In case you don'
On Thu, Jan 05, 2006 at 03:06:59PM -0800, Paul Eggert wrote:
> [EMAIL PROTECTED] (James Youngman) writes:
>
> > I would prefer an arrangement which results in a compilation or link
> > failure if the user (i.e. software maintainer) fails to initialise
> > things properly.
>
> Perhaps we could ch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 1/5/2006 4:06 PM:
>
>>Is it a problem in practice, ie, what are these non-Unix linkers?
>
>
> I've run into it on IBM mainframe platforms. You can run into it even
> with GCC, if you use -fno-common. Googling a bit reve
Paul Eggert <[EMAIL PROTECTED]> writes:
> 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.)
Sorry, I thought Unix linkers actually did reject it, which was
[EMAIL PROTECTED] (Karl Berry) writes:
> Is it a problem in practice, ie, what are these non-Unix linkers?
I've run into it on IBM mainframe platforms. You can run into it even
with GCC, if you use -fno-common. Googling a bit reveals that libtool
1.5 uses -fno-common on Mac OS X (why, I don't k
On Thu, Jan 05, 2006 at 02:03:27PM -0800, Paul Eggert wrote:
> 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
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.)
Is it a problem in practice, ie, what are these non-Unix linkers?
How about defining it in error.c w
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 gnul
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
Dave Love <[EMAIL PROTECTED]> writes:
> 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.
Under the current approach, it's the caller's responsibility to arrang
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; if gnulib supports
23 matches
Mail list logo
