Re: Merge getopt from gnulib to glibc and vice versa, eliminate __need_getopt

[Zack Weinberg <zackw at panix dot com>]

On Thu, Apr 6, 2017 at 6:48 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
> Thanks for doing this, as Gnulib and Glibc should be better-synchronized. In
> the interests of helping this move along, I installed your proposed changes
> into Gnulib, with the attached additional minor patches, the first of which
> I hope you can incorporate into your Glibc proposal (the second patch is
> Gnulib-only). Perhaps other reviewers will come up with other Gnulib and/or
> Glibc improvements, but one step at a time.

Great!  I'm going to take this as sufficient review to go ahead and
merge the entire patchset on the glibc side as well.  I don't think
there's anyone else who knows getopt itself as well as you do, I'm
confident that any problems will be minor and addressable in follow-up
patches, and I don't want to be left with a situation where there is
*massive* divergence between gnulib and glibc here for an extended
period.

I've also pushed your follow-on change to getopt1.c.

> * Gnulib lib/getopt_cdefs.in.h, lib/getopt_core.h, lib/getopt_ext.h,
> lib/getopt_pfx_core.h, and lib/getopt_pfx_ext.h now all have comments saying
> "Unlike most bits headers, it does not have a protective #error, because the
> guard macro for getopt.h in gnulib is not fixed." What sort of Gnulib fix
> did you have in mind? Is this something we can easily fix in Gnulib now?

This is just meant to reassure people reading the code in glibc that
the omission of

#ifndef _GETOPT_H
# error "Don't include bits/whatever.h directly, include getopt.h instead"
#endif

from these headers is intentional and not a bug.  Maybe we could
improve the wording of the comment, but I don't think there's anything
that actually needs fixing on the gnulib side.

> * From Gnulib's point of view, perhaps it would be better to define a module
> for sys/cdefs.h, and have the Gnulib getopt-posix module depend on this new
> module. That way, other Gnulib code could assume a standard GNU system which
> has sys/cdefs.h. Does this seem like a reasonable way forward to you? It
> shouldn't affect glibc code, other than perhaps to simplify it a bit.

Yes.  But note that sys/cdefs.h exists in BSD as well, with an
overlapping set of definitions -- see for instance
https://github.com/freebsd/freebsd/blob/master/sys/sys/cdefs.h.  It's
not a GNU invention.

> * Although the Gnulib project prefers to omit leading tabs in .c and .h
> files, it's OK to put tabs in files shared from glibc, at least while we're
> doing this merge. I suppose Gnulib developers who prefer to avoid tabs can
> expand them later, once the merging is done. Personally I would rather let
> sleeping dogs lie.

glibc still adheres to the strict leading-tabs policy that I think is
still written into the GNU coding standard.  I suppose there might be
a case for relaxing it for files shared with gnulib, but I am also
content to let it lie.  More important, in my opinion, that 'diff -u
gnulib/lib/getopt.c glibc/posix/getopt.c' reports no changes.

zw