[Bug-gnulib] Re: getopt trouble on uClibc systems

[Paul Eggert]

Simon Josefsson <address@hidden> writes:

> Perhaps it would be useful to have several modules (probably sharing
> the same source code files):

That would take more work, and I'm not sure the work would be that
useful; please see below.

> getopt: gl_FUNC_GETOPT - POSIX.2 implementation, no more no less, used
>                          when getopt is all the application want, and
>                          the system doesn't provide getopt.

Yes, this might be useful for non-GNU programs, but GNU programs
should never need it, so it's low priority.

> getopt_long: gl_FUNC_GETOPT_LONG - Like 'getopt', but also add GNU
>                                    extension that doesn't conflict
>                                    with system implementations, i.e.
>                                    this is what most people looking
>                                    for only 'getopt_long' will want.
> getopt_redefine: gl_GNU_GETOPT - Override the system 'getopt' with the
>                                  one found in the 'getopt_gnu' module.
>                                  This is for applications that depend
>                                  on the GNU extensions inside the
>                                  'getopt' function.

I don't think we'll need both of these macros.  Generally speaking,
programs that use getopt_long don't use getopt.  Conversely, it's hard
for me to think of an application that wants the GNU extensions to
getopt, but doesn't want getopt_long.  It's possible, but not likely.

> getopt_gnu: gl_FUNC_GETOPT_GNU - Name space clean GNU getopt implementation.
>                                  i.e., the 'getopt' with GNU extensions is
>                                  called 'getopt_gnu'.

I doubt anybody will ever use this.

So, in all, I think we need only one macro as a high-priority item.
(And we might as well call it gl_GETOPT, as it's what users expect
already....)

> I don't like the rpl_ stuff.

The rpl_ stuff is essential when replacing functions like 'malloc', as
the C Standard doesn't allow one to define a C-Standard external
symbol like 'malloc', and many platforms rely on this restriction.
Also, many platforms have similar requirements even for symbols like
'getopt' that are outside the C Standard (such platforms violate the C
Standard, but I'm afraid that's life).

> I have had troubles with AC_DEFINE re-defining core functions when
> only parts of my project links with gnulib -- I typically don't want
> to link gnulib in my libraries, but I want to make use of it in a
> library command line interface.  I'll see if I can get it to work
> without it.

If you don't want gnulib in your libraries, but you do want it in your
library, then I'm afraid you need to have a different config.h for
your command-line interface than you do for your library -- at least
if you use the part of gnulib that redefines symbols like 'malloc'.  I
don't see an easy way around this problem.

> instead of renaming the gnulib implementation, the code should check
> whether the symbol is available, and if so use it.

That sounds reasonable, for getopt.

> The only situation where a AC_DEFINE may be warranted is if you really
> are re-defining already existing functionality.  Was this the only
> reason here?

Yes, that's the basic idea behind rpl_.  But you're right, it's not
essential for getopt.

> GETOPT_H=getopt.h
> AC_SUBST([GETOPT_H])
> AC_LIBOBJ(getopt1)
> AC_LIBOBJ(getopt)

So far so good.

> AC_CHECK_DECLS([optfoo, optopt, optind, opterr, getopt])

"optfoo" should be "optarg".

But you don't want to check whether these symbols are declared; you
want to check whether they're defined.  (The distinction between
definition and declaration is how this whole thread started....)
That is, in:

> #if !HAVE_DECL_OPTIND
> int optind = 1;
> #endif

optind should be defined if it isn't supplied by the library; it
shouldn't matter whether it's declared.  (You're not using the
system-defined declaration for optind anyway.)

> #if !HAVE_DECL_GETOPT
> int
> getopt (int argc, char *const *argv, const char *optstring)

Similarly for getopt.

Otherwise I think the approach will work and is a good idea.  There
would be a problem if nonstandard implementations used different types
for optind, optarg, etc., but I think this unlikely.