Re: recommending AC_SYS_YEAR2038_REQUIRED ?

[Zack Weinberg]

On Wed, Apr 19, 2023, at 5:23 PM, Paul Eggert wrote:
> On 2023-04-11 17:10, Zack Weinberg wrote:
>> I'm also happy with this resolution.  I do not have time to do the Autoconf 
>> work until the weekend.
>
> I notice you were careful to not say *which* weekend. :-)

Ugh. Yeah. Don't expect anything out of me before the end of CMU's spring term 
(second week of May) at the absolute earliest.

zw

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

[Zack Weinberg]

On Mon, Apr 10, 2023, at 7:00 PM, Paul Eggert wrote:
> On 2023-04-10 15:36, Bruno Haible wrote:
>> I like this. Thanks.
>
> OK, then let's hear Zack's opinion and hopefully move forward.

I'm also happy with this resolution.  I do not have time to do the Autoconf 
work until the weekend.

zw

Re: recommending AC_SYS_YEAR2038_REQUIRED ?

[Zack Weinberg]

On Mon, Apr 10, 2023, at 10:12 AM, Pádraig Brady wrote:
> On 10/04/2023 14:40, Bruno Haible wrote:
>> Hi Paul, In yesterday's changes, you added to the Gnulib
>> documentation, section "Avoiding the year 2038 problem", wording that
>>
>>* explicitly recommends the ‘year2038-required’ module, which does
>>  AC_REQUIRE([AC_SYS_YEAR2038_REQUIRED]):
...
>> I strongly object to this recommendation and presentation.
...
>> It is simply the wrong person's decision if the package maintainer
>> uses the AC_SYS_YEAR2038_REQUIRED macro.
...
>> When AC_SYS_YEAR2038_REQUIRED is used, the package can no longer be
>> installed on the following 32-bit platforms/ABIs:
...
>> I would therefore propose that the module 'year2038-required' gets
>> removed from Gnulib, as I cannot see any positive uses of it.

As the person who invented AC_SYS_YEAR2038_REQUIRED and
AC_SYS_LARGEFILE_REQUIRED, let me say that it was my intention that they
would only be used in rare circumstances, where the inability to install
the software on older ABIs is outweighed by some other strong
requirement for time_t and/or off_t to be at least 64 bits.  I didn't
have any specific use cases in mind but I was imagining something to do
with library ABIs involving time_t, or network and/or storage formats
explicitly specified to use 64-bit counts of seconds since the Unix
epoch, or similar.

zw

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Zack Weinberg]

On Wed, Nov 16, 2022, at 1:17 PM, Paul Eggert wrote:
...
> If Clang's threatened pickiness were of some real use elsewhere, it 
> might be justifiable for default Clang to break Autoconf. But so far we 
> haven't seen real-world uses that would justify this pickiness for 
> Autoconf's use of 'char memset_explicit(void);'.

I don't have time this week to really get into this argument but I want to 
point out that I'm generally in agreement with Rich Felker's argument (in 
https://ewontfix.com/13/) that AC_CHECK_FUNC *should not* just probe for 
linkability of a symbol, because:

 - Not including the appropriate headers means that the probe bypasses 
compile-time symbol renaming and therefore probes for *the wrong symbol*, 
potentially causing both false detection and false non-detection (to tie it to 
another subthread, notice that one of the things -D_TIME_BITS=64 triggers (from 
glibc's headers) is enable dozens of __REDIRECT annotations in time.h)

 - Only probing the symbol, and not its type signature, means for instance that 
if the program expects GNU strerror_r but the system provides POSIX strerror_r, 
or vice versa, Autoconf's check will succeed but the program will fail to 
compile (in more subtle cases it might be miscompiled instead)

(N.B. I *don't* agree with the assertion at the bottom of that page that 
"taking explicit action to prevent linking against [symbols intended to be 
exposed for binary compatibility only], involves hacks that are even worse and 
more fragile than what configure is doing" -- yes, it sucks that the toolchain 
support for ELF symbol versioning is still mostly absent, 20 years after the 
concept was introduced, but `asm(".symver __strtod_l_compat, 
strtod_l@SOME_CONCRETE_VERSION_TAG")` is straightforward (if cryptic) and 
robust on all the platforms where it works at all.)

zw

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Zack Weinberg]

On Tue, Nov 15, 2022, at 12:03 AM, Sam James wrote:
>> On 13 Nov 2022, at 00:43, Paul Eggert  wrote:
>> 
>> Although there will be problems with people who run "./configure 
>> CFLAGS='-Werror'", that sort of usage has always been problematic and 
>> unsupported by Autoconf, so we can simply continue to tell people "don't do 
>> that".
>> 
>
> Is there somewhere in the autoconf docs we actually say this?
>
> I've seen a few instances of folks adding it themselves very
> early in their configure scripts (which is a pain for distros
> anyway) which then ends up affecting the rest.

It's mentioned in the NEWS entry for 2.70: 
https://git.savannah.gnu.org/cgit/autoconf.git/tree/NEWS#n170

It should be discussed in the actual manual as well, but I've been reluctant to 
add anything about warnings to the manual as long as Autoconf proper doesn't 
have any support for controlling warnings.

Note that there have been bug reports for cases where running builds with more 
warnings than configure uses (and I think also -Werror), means that configure 
checks spuriously succeed (i.e. configure reports that something is available, 
but then you get compiler errors on the code that tries to use it).  I can't 
remember any concrete examples right now, though.

zw

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Zack Weinberg]

Demi Marie Obenour  writes:
> On 11/10/22 15:19, Paul Eggert wrote:
>> Here's the main Autoconf issue issue with bool. Traditionally, Autoconf 
>> supported K&R C, C89, C99, etc. At some point (I'm not sure when), 
>> Autoconf started requiring C89 or later. Is it now OK for Autoconf to 
>> require C99 or later, as far as bool is concerned? If so, that'll 
>> considerably simplify the ongoing maintenance hassle for bool.
>>
>> Requiring C99-or-later bool is the option that Gnulib has taken. Its 
>> 'stdbool' module and its gl_C_BOOL macro assumes C99 or later, and as 
>> far as I know no Gnulib-using package is using Gnulib's 'stdbool-c99' 
>> module which we kept around in case somebody still needed bool to work 
>> atop a C89 system. (We considered supporting C23 bool atop C89 but it 
>> was too painful.)
>
> I am fine with this option.

On the whole I’m also fine with this, but I think we need to consider,
separately, two kinds of Autoconf-using packages and three kinds of
compilers.

I think it’s definitely fine if Autoconf-using packages that request
support for ‘bool’, using either AC_C_BOOL or gl_C_BOOL, start requiring
a C99 compiler as of 2.72 (but see below).  I suspect there are existing
packages (Kermit comes to mind) that intend to maintain compatibility
with C89 compilers *forever*, and will choose *not* to use AC_C_BOOL,
and will be annoyed if AC_PROG_CC by itself starts rejecting C89 compilers.

(We may eventually decide we don’t support C89 compilers *at all*
anymore but that should be an independent discussion and not driven by
‘bool’.)

Then, on the compiler side of things, there’s compilers that have
complete support for ‘bool’ as it was specified in C99 (i.e. both the
‘_Bool’ keyword is recognized and a useful ‘stdbool.h’); there’s
compilers that have ‘_Bool’ but *don’t* have a useful ‘stdbool.h’; and
there’s compilers that don’t have any “true Boolean type” (as I put it
in the manual) at all.  In earlier discussions, IIRC, we determined that
compilers in all three of these categories do exist.

I suggest that what we mean by “Packages that use AC_C_BOOL require a
C99 compiler” is precisely “When @code{AC_C_BOOL} is used,
@command{configure} will error out if the C compiler does not recognize
either @samp{bool var;} or @samp{_Bool var;} as a valid complete
translation unit.”  In other words, the third category of compilers, the
ones that don’t have any “true Boolean type” (whose name we know), are
rejected.  However, compilers in the second category (_Bool available,
stdbool.h either unavailable or does not work) will be accepted and
config.h will perform the #defines that stdbool.h ought to have
performed.

> I just checked and both GCC 12.2 and clang 14 support  in C89
> mode.  I do get a -Wc99-extensions warning from clang but that can easily
> be suppressed with -Wno-c99-extensions.

Good to know, thanks.

zw

Re: On time64 and Large File Support

[Zack Weinberg]

Sam James  writes:

>> On 12 Nov 2022, at 02:20, Zack Weinberg via Libc-alpha 
>>  wrote:
>> I am honestly not sure what to do about this in the long term, but for
>> the proposed “this weekend, just bugfixes” Autoconf 2.72, I do think it
>> makes sense to back out change #2, only — that is, AC_SYS_YEAR2038 will
>> exist, but AC_SYS_LARGEFILE will *not* imply AC_SYS_YEAR2038.  That will
>> limit the impact of AC_SYS_YEAR2038 to packages that have explicitly
>> added it, and should make it safe for Fedora and Gentoo to drop in 2.72
>> in order to unblock C23 testing — am I correct?  It doesn’t resolve the
>> larger issue, but it gives us more time to think about what the
>> resolution ought to be.
>> 
>> What do you think?
>
> This is really I think the best option while allowing us time & space
> to complete the larger discussion.
[…]

I am going to go ahead and do this if nobody raises a concrete objection
within the next 24 hours.

zw

Re: On time64 and Large File Support

[Zack Weinberg]

Sam James  writes:
>> On 11 Nov 2022, at 09:19, Florian Weimer  wrote:
>> We need to support legacy binaries on i386.  Few libraries are
>> explicitly dual-ABI.  Whether it's safe to switch libraries above glibc
>> to LFS or time64 needs to be evaluated on a per-library basis.  For most
>> distributions, no one is going to do that work, and we have to stick to
>> whathever we are building today.
>
> While I agree, I don't think it's as well-known that it should be that
> these are ABI breaking and require inspection. It's being done ad-hoc
> or in many cases, not at all.
…
>>> We're now (possibly) on the eve of an autoconf 2.72 release which
>>> contains two changes of note [2][3]
>>> 1. addition of a new AC_SYS_YEAR2038 macro;
>>> 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.
>>> 
>>> Indeed, the gnulib version of change #2 is exactly how we ended up with
>>> wget/gnutls breaking [1]. I feel this shows that the only approach
>>> "supported" by glibc right now is untenable.
>> 
>> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
>> for Fedora unfortunately.
>> 
>> I thought the gnulib change has been reverted?
>> 
>> I really wish the rest of GNU would talk to glibc maintainers before
>> overriding glibc maintainer decisions.

There seems to be a disconnect between Paul Eggert’s position on these
changes and everyone else on this thread’s position.

I don’t think Paul considered the new behavior of AC_SYS_LARGEFILE to be
overriding the glibc maintainers. Rather, I think he was only thinking
about applications, not libraries, and only about source distribution.
If an application is being built on the machine where it’ll be used, and
both it and the system support building it with 64-bit time_t and off_t,
*why wouldn’t you*?  It has no impact on anything else to do that, and
it future-proofs your installataion.

But everyone else is worrying about cases where, either, an application
is built with 64-bit time_t and/or off_t and then copied to a different
system where the underlying libraries *don’t* support that, or a *shared
library* is rebuilt with 64-bit time_t and/or off_t and that silently
changes its ABI out from under programs that use it.

(It’s unfortunate, IMNSHO, that glibc chose not to provide a time_t
equivalent of _LARGEFILE64_SOURCE, as this means it’s much more
difficult for any shared library other than glibc to offer *both* time_t
and time64_t binary interfaces.)

(It’s also unfortunate that, 20+ years after the invention of ELF symbol
versioning, it’s still ridiculously difficult.  So many macros and
assembly hacks and fighting with libtool.  But I digress.)

I am honestly not sure what to do about this in the long term, but for
the proposed “this weekend, just bugfixes” Autoconf 2.72, I do think it
makes sense to back out change #2, only — that is, AC_SYS_YEAR2038 will
exist, but AC_SYS_LARGEFILE will *not* imply AC_SYS_YEAR2038.  That will
limit the impact of AC_SYS_YEAR2038 to packages that have explicitly
added it, and should make it safe for Fedora and Gentoo to drop in 2.72
in order to unblock C23 testing — am I correct?  It doesn’t resolve the
larger issue, but it gives us more time to think about what the
resolution ought to be.

What do you think?
zw

Re: bool and C23

[Zack Weinberg]

Please note consolidated reply to both Paul and Bruno.

On Sun, Aug 21, 2022, at 5:25 PM, Paul Eggert wrote:
> On 8/21/22 07:59, Zack Weinberg wrote:
>> Paul Eggert:
>>> Zack Weinberg:
>>>> @defmac AC_C_BOOL (@ovar{if-required})
>>>
>>> How about if we omit the IF-REQUIRED parameter?
>>
>> Taking out the "optional" mode will mean that regenerating the the
>> configure script of a package that uses the stdbool module, with
>> Autoconf 2.72, will quietly bump its minimum C compiler requirement
>> to C99.  Are we okay with that?
>
> Yes, I think so. I believe Gawk was the last Gnulib-using project that
> wanted portability to C89, and Gawk dropped that requirement a few years
> ago.

OK, I’ll proceed on the assumption this is fine unless we hear
otherwise, and I’ll make sure both Autoconf NEWS and the manual make
the implications clear.

> More precisely, the idea is that in
> <https://www.gnu.org/software/gnulib/manual/html_node/C99-features-assumed.html>
> we'd change ", assuming the stdbool module is used. See
> stdbool.h." to something like "bool, true, and false (perhaps via
> ); see the bool module." The stdbool module would become
> obsolescent.

There isn’t a bool module right now, are you proposing to add one?
To be clear, I want to get to where _no_ Gnulib module is required for
bool; AC_C_BOOL by itself should be enough.

>> I think we still need C_BOOL_DEFINITION even if we make that change,
>> because apparently there exist(ed?) compilers that provide _Bool but
>> not stdbool.h.
>
> Apparently OS X had that problem as recently as 2018
> <https://github.com/carp-lang/Carp/issues/332> so I guess such a
> workaround would be helpful for some apps. I'm not sure Gnulib will need
> it though.

Again, AC_C_BOOL by itself is supposed to be all you need (in the
common case where autoheader is in use).

> Sure, but why can't the non-autoheader case define bool, false, and true
> instead of defining C_BOOL_DEFINITION? That will keep the code simpler
> for these people.

I don’t understand what you are suggesting here.

> one possibility
> is that 'true' is defined by the system's  which says
> "#define true (!0)". The C standard allows this.

I don’t think it does? N1570 (C11-in-all-but-name) 7.18p3 says “`true`
expands to the integer constant 1” and “`false` expands to the integer
constant 0.”  No leeway at all there.  I don’t have my copy of C99 on
this computer, but I doubt it says anything different.

>> I meant to ask you why the Gnulib stdbool module uses "signed char"
>> as the fallback underlying type for bool.
>
> I don't recall exactly but I can imagine a couple of good reasons.
> First, it makes it more likely you'll get a type clash if you mistakenly
> confuse int for bool in function signature compiled by an older
> compiler. Second, it makes it less likely that there would be a clash if
> some code is compiled with a compiler that has a working bool of size 1
> (the most common implementation I think), whereas other code is compiled
> with Gnulib's substitute for bool.

Hm, OK, I guess.  I’m still worried about undesirable integer
promotions but I guess those happen with _Bool used in arithmetic
expressions too (since it has the lowest possible integer conversion
rank).

On Sun, Aug 21, 2022, at 5:34 PM, Bruno Haible wrote:
>   * In C++ mode,
[…]
> [cstdbool may include] various OS stuff, and should therefore be
> avoided when possible. Since a compilation unit cannot be ISO C 23
> and C++ at the same time, it is easy to achieve: Wrap the new
> config.h additions in
>   #ifndef __cplusplus
>   ...
>   #endif

Yes, this was already my plan.  Do you think it’s worth mentioning
this issue in Autoconf’s documentation (it already says “stdbool.h
should not be included from C++” but not why).

>   * In C mode: […] it is OK to #include , since it
> does not include header files with function declarations, only
> header files with macro definitions.

We _could_ still get errors from -Wredundant-decls -Werror or
equivalent, but I think that’s probably okay to live with.

>   - Determine GL_GENERATE_STDBOOL_H as in gnulib/m4/stdbool.m4,

It looks like the only thing gl_STDBOOL_H does, that my current draft
of AC_C_BOOL doesn’t do, is refuse to use an existing  from
C++ on Solaris.  Given that my current draft _never_ uses 
from C++, I think we can just scrap that part.

Looking at the existing Gnulib code, though, suggests another possible
reason why we might need the fallback code to `signed char` (or
Gnulib’s enumeration): allegedly C99-compliant compilers whose Boolean
implementation is buggy.  My AC_C_BOOL preserves the existing test for
a buggy Boolean type, from AC_CHECK_HEADER_STDBOOL, so, if we do as
Paul suggests and make configure error out when there’s no usable
Boolean, that will hard reject those compilers as well.  I’m fine with
that.  Are you fine with that?

zw

Re: Request to revert the C version change

[Zack Weinberg]

On Sun, Dec 20, 2020 at 12:09 PM Zack Weinberg  wrote:
> I'm not happy about needing to kludge backward compatibility with the
> older std-gnu11.m4 into autoconf 2.70.1 but I'm going to do it.

As of commit 2d0f19d84ddb13412382674fd48e6fc5c2875d0e, Autoconf
*trunk* should now be backward compatible with the older std-gnu11.m4.
I verified that I can regenerate bison 3.7.4's configure script with
that version of Autoconf, making no other changes to the bison release
tarball, and then configure, build, and test bison with no errors.

The patch is somewhat invasive, though.  The full text is attached,
and before I merge it to the 2.70 branch, I'd appreciate any extra
testing and/or code review anyone cares to give it.

zw
From 2d0f19d84ddb13412382674fd48e6fc5c2875d0e Mon Sep 17 00:00:00 2001
From: Zack Weinberg 
Date: Mon, 21 Dec 2020 14:04:22 -0500
Subject: [PATCH] Restore compatibility with older std-gnu11.m4.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Gnulib’s std-gnu11.m4 backports C11 and C++11 detection to autoconf
2.69.  It does this by replacing the definitions of AC_PROC_CC and
AC_PROG_CXX and most of their subroutines.  In particular, it replaces
the definitions of _AC_PROG_CC_C11, _AC_PROG_CC_C99, and _AC_C_STD_TRY,
but it does *not* replace the definition of _AC_PROG_CC_C89.

Autoconf commit 131d8c69f31dc6fc8dc93abe1096d52d1fe19fd3 changed the
calling convention of _AC_C_STD_TRY, and changed the internal
definitions of _AC_PROG_CC_C{11,99,89} to match.  If std-gnu11.m4 is
in use, our _AC_PROG_CC_C89 calls their _AC_C_STD_TRY with the new
calling convention, and this produces a syntactically invalid
configure script.  (This is is fortunate: it could easily have been a
runtime malfunction that only manifested with compilers that only
implement C89, and then we might not have noticed the problem for
years.)

Gnulib commit a3b3fc85e3e632374811b27cb2111e50fa177e36 makes
std-gnu11.m4 do nothing when used with autoconf >=2.70, but older
versions of the file will circulate for years to come, so this patch
works around the problem in autoconf.  It does this by renaming all of
the internal macros involved with C and C++ standard edition
detection, *except* _AC_PROG_CC_C89.  AC_PROG_CC now calls
_AC_PROG_CC_STDC_EDITION, which loops over all supported editions
calling _AC_PROG_CC_STDC_EDITION_TRY, which uses the data provided by
the existing _AC_C_C${edition}_TEST_PROGRAM macros and a new set of
macros called _AC_C_C${edition}_OPTIONS to perform the test for that
edition of the standard.  Similarly, AC_PROG_CXX calls
_AC_PROG_CXX_STDCXX_EDITION, which loops calling
_AC_PROG_CXX_STDCXX_EDITION_TRY, which uses data from
_AC_CXX_CXX${edition}_TEST_PROGRAM and _AC_CXX_CXX${edition}_OPTIONS.

_AC_PROG_CC_C89 is the only macro from the old set that we still
define, and its definition is reverted to what std-gnu11.m4 expects it
to be.  Nothing in Autoconf proper uses it anymore.

foreign.at grows a test to verify that the compatibility stub version
of _AC_PROG_CC_C89 does its job.  Since this is now the third test
involving an embedded copy of a third-party macro, I broke them all
out of foreign.at to separate files in test/data/.

In addition to fixing the breakage, this patch should make it easier
to extend C / C++ standard edition detection in the future, by getting
rid of the if-else chains in AC_PROG_CC/CXX and by disentangling the
lists of command-line options to test from the logic.

I also changed the manual to suggest people refer to the variables
‘ac_prog_cc_stdc’ and ‘ac_prog_cxx_stdcxx’ to learn which edition
of the C and C++ standards are selected; these are much easier to
work with than the ac_cv_prog_cc_cNN cache variables.

* lib/autoconf/c.m4 (_AC_C_STD_TRY, _AC_PROG_CC_C99, _AC_PROG_CC_C11)
  (_AC_CXX_STD_TRY, _AC_PROG_CXX_CXX98, _AC_PROG_CXX_CXX11): Remove macro.

  (_AC_C_C89_OPTIONS, _AC_C_C99_OPTIONS, _AC_C_C11_OPTIONS)
  (_AC_PROG_CC_STDC_EDITION, _AC_PROG_CC_STDC_EDITION_TRY)
  (_AC_CXX_CXX98_OPTIONS, _AC_CXX_CXX11_OPTIONS)
  (_AC_PROG_CXX_STDCXX_EDITION, _AC_PROG_CXX_STDCXX_EDITION_TRY): New macros.

  (_AC_PROG_CC_C89): Convert to compatibility stub for std-gnu11.m4.

  (AC_PROG_CC): Use _AC_PROG_CC_STDC_EDITION.
  (AC_PROG_CXX): Use _AC_PROG_CXX_STDCXX_EDITION.

* tests/data/ax_prog_cc_for_build_v18.m4
* tests/data/ax_prog_cxx_for_build_v3.m4
* tests/data/gnulib_std_gnu11_2020_08_17.m4: New files.
* tests/foreign.at (AX_PROG_CC_FOR_BUILD, AX_PROG_CXX_FOR_BUILD):
  Remove embedded copy of ax_prog_cc_for_build_v18.m4,
  ax_prog_cxx_for_build_v3.m4 respectively.
  (gnulib-std-gnu11.m4): New test.
* tests/local.mk: Distribute tests/data/*.m4.

* doc/autoconf.texi (AC_PROG_CC, AC_PROG_CXX): Document use of
  ac_prog_cc_stdc / ac_prog_cxx_stdcxx, respectively, to tell which
  edition of the C / C++ standards are selected, instead of looking
  through a series of cache variables with awkward defini

Re: Request to revert the C version change

[Zack Weinberg]

On Sun, Dec 20, 2020 at 12:09 PM Zack Weinberg  wrote:

> I'm not happy about needing to kludge backward compatibility with the
> older std-gnu11.m4 into autoconf 2.70.1 but I'm going to do it.


It occurs to me that this would be less of a problem in the future if
aclocal/autoreconf could update M4 files originally from gnulib and
autoconf-archive. Obviously too late to help with this specific issue, but
something to think about for the future.

zw

Re: Request to revert the C version change

[Zack Weinberg]

On Sun, Dec 20, 2020 at 11:54 AM Ross Burton  wrote:
> On Sun, 20 Dec 2020 at 16:46, Bruno Haible  wrote:
>> This patch is already in Gnulib since 2020-12-09. But when people
>> run 'autoreconf' on an existing released tarball, they are effectively
>> combining an older Gnulib with a newest Autoconf.
>>
>> Why do people do that? The point of tarballs is that you can run
>> './configure' right away.
>>
>> If people want to modify the build infrastructure, it would often be
>> more reasonable to start off the git repository of the package (possibly
>> from a specific release tag or release branch).
>
> Because it’s not uncommon to need newer config.status, or updated m4 files, 
> or to patch Makefile.am or configure.ac.

Also, in my experience downstream redistributors prefer to work from
tarballs, for several different reasons: tarballs tend to come with
more provenance information (e.g. PGP signatures); working from a git
checkout may require any number of unusual tools that aren't required
for tarball releases; figuring out exactly which git commit
corresponds to a tarball is often more difficult than it ought to be;
and so on.

I'm not happy about needing to kludge backward compatibility with the
older std-gnu11.m4 into autoconf 2.70.1 but I'm going to do it.

zw

Re: Request to revert the C version change

[Zack Weinberg]

On Sun, Dec 20, 2020 at 11:46 AM Bruno Haible  wrote:
>
> Zack Weinberg wrote:
> > $ diff -u m4/std-gnu11.m4{~,}
> > --- m4/std-gnu11.m4~2020-08-30 11:27:01.0 -0400
> > +++ m4/std-gnu11.m42020-12-20 09:43:13.001477099 -0500
> > @@ -27,6 +27,8 @@
> >  # François Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
> >  # Roland McGrath, Noah Friedman, david d zuhn, and many others.
> >
> > +m4_version_prereq([2.70], [], [
> > +
...
> >
> > I recommend this patch be applied in Gnulib proper.
>
> This patch is already in Gnulib since 2020-12-09.

Thanks for letting me know, I forgot to update my Gnulib checkout
before posting.

zw

Re: Request to revert the C version change

[Zack Weinberg]

On Wed, Dec 16, 2020 at 2:02 PM Zack Weinberg  wrote:
> On Wed, Dec 16, 2020 at 1:52 PM Ross Burton  wrote:
> > | checking for gcc  option to enable C11 features... none needed
> > | ../bison-3.7.4/configure: line 6187: syntax error near unexpected
> > token `ac_cv_prog_cc_stdc=$ac_cv_prog_cc_c89'
> > | ../bison-3.7.4/configure: line 6187: `
> > ac_cv_prog_cc_stdc=$ac_cv_prog_cc_c89'
> >
> > gettext failed in the same manner.
> >
> > I can bisect and identify where it broke tomorrow.
>
> Thanks.  This is definitely not a failure I saw in my testing, but it
> smells like another typo in the shell code, so hopefully not hard to
> fix.

The problem appears to be that gnulib's std-gnu11.m4 replaces *most*
of the definition of AC_PROG_CC, in a way that conflicts with the
refactor.  I'm looking for a way to avoid the conflict within autoconf
proper, but a workaround is to apply this patch to std-gnu11.m4:

$ diff -u m4/std-gnu11.m4{~,}
--- m4/std-gnu11.m4~2020-08-30 11:27:01.0 -0400
+++ m4/std-gnu11.m42020-12-20 09:43:13.001477099 -0500
@@ -27,6 +27,8 @@
 # François Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
 # Roland McGrath, Noah Friedman, david d zuhn, and many others.

+m4_version_prereq([2.70], [], [
+

 # AC_PROG_CC([COMPILER ...])
 # --
@@ -822,3 +824,5 @@
 dnl with extended modes being tried first.
 [[-std=gnu++11 -std=c++11 -std=gnu++0x -std=c++0x
-qlanglvl=extended0x -AA]], [$1], [$2])[]dnl
 ])# _AC_PROG_CXX_CXX11
+
+])# m4_version_prereq

I recommend this patch be applied in Gnulib proper.  It may be wise to
go through all of gnulib's m4 files and see if any others need the
same treatment.  (Any m4 file that backports code from the development
series leading up to 2.70 is a candidate.)

zw

Re: Hidden files in autoconf 2.70 distribution?

[Zack Weinberg]

On Wed, Dec 9, 2020 at 9:18 AM Bob Friesenhahn
 wrote:
> On Tue, 8 Dec 2020, Zack Weinberg wrote:
> >
> > Yes, that’s intentional. Those files record information copied out of the
> > git history. See build-aux/git-version-gen and maint.mk.
>
> I don't recall seeing "hidden" files in a GNU package (or really any
> tarball distribution) before.  It seems like the GNU coding standards
> should be addressing such things.
>
> The files appeared in autoconf-2.69c and were not in autoconf-2.69b.

This conversation should happen on the Gnulib mailing list; both
git-version-gen and maint.mk are maintained there.  I have no
particular opinion about whether it is appropriate to use dot-files
for this purpose.

(Context that got trimmed off the top: Bob is concerned about the
files named ".prev-version", ".version", and ".tarball-version" in the
autoconf 2.70 release tarball.)

zw

[PATCH] sc_error_message_uppercase: allow fully uppercased words

[Zack Weinberg]

If an error message starts with an entire fully uppercased word,
that’s probably a proper noun and it should stay that way.  For
instance, autoreconf has an error message that starts with
"AM_GNU_GETTEXT is used, but ..."; AM_GNU_GETTEXT is the name of an
Automake macro, it needs to stay uppercased.

This subsumes the existing exception for the words FATAL and WARNING.
While I was in there I generalized the exception for PRIuMAX to cover
all of the inttypes.h PRI* and SCN* macros.

* maint.mk (sc_error_message_uppercase): Allow error messages that
  begin with any fully uppercased word, or with any of the inttypes.h
  PRI[dioux]\w+ or SCN[dioux]\w+ macros.
---
 maint.mk | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/maint.mk b/maint.mk
index 2a0d2b4c..c2a9333c 100644
--- a/maint.mk
+++ b/maint.mk
@@ -464,12 +464,15 @@ sc_error_message_warn_fatal:
   exit 1; }\
  || :
 
-# Error messages should not start with a capital letter
+# Error messages should not start with a capital letter;
+# however, if they start with an entire fully uppercased word, that's
+# probably a proper noun and it should stay that way.  We also exempt
+# known instances of proper nouns that should stay mixed-case.
 sc_error_message_uppercase:
@$(VC_LIST_EXCEPT)  \
  | xargs $(GREP) -nEA2 '[^rp]error *\(' /dev/null  \
  | $(GREP) -E '"[A-Z]' \
- | $(GREP) -vE '"FATAL|"WARNING|"Java|"C#|PRIuMAX' \
+ | $(GREP) -vE '"([A-Z0-9_]{2,}\>|Java|C#|(PRI|SCN)[dioux])'   \
  && { echo '$(ME): found capitalized error message' 1>&2;  \
   exit 1; }\
  || :
-- 
2.29.2

Re: AS_IF

[Zack Weinberg]

On Mon, Oct 12, 2020 at 3:01 AM Paul Eggert  wrote:
> On 10/6/20 5:52 PM, Zack Weinberg wrote:
> > I'm not sure we should say AS_IF/CASE
> > are equivalent to plain shell if/case inside an AC_DEFUN; they do do
> > more than just make the m4 expansion stack not be empty.
>
> Yes, that goes a bit too far. I installed the attached doc patch to Savannah
> Autoconf master to try to clarify things a bit. I developed this patch before
> seeing Bruno's, but it should address the same issues (plus a few more, like
> portability of Posix case syntax).

Looks good, thanks.

> AS_FOR is kind of a mess. I wouldn't document it the way it is. Perhaps it 
> could
> be cleaned up in some future Autoconf version.

Oh, yeah, I see what you mean now.  I didn't actually read the
definition of AS_FOR before writing that NEWS entry.

zw

Re: AS_IF

[Zack Weinberg]

On Tue, Oct 6, 2020 at 5:57 PM Bruno Haible  wrote:
> Paul Eggert wrote in
> :
> > > AFAICS, this is relevant for code written directly into configure.ac. But
> > > inside an AC_DEFUN it is irrelevant, because required macros are hoisted
> > > before the body of the AC_DEFUN anyway.
...
> > But now that you mention it, AS_IF isn't needed here and I installed the
> > attached further patch. Also, to help prevent others from making a similar
> > mistake, I plan to reword the Autoconf NEWS item to start with something 
> > like
> > "Autoconf macros that use AC_REQUIRE are not safe to use in hand-written 
> > shell
> > control-flow constructs that appear outside of macros defined by AC_DEFUN."
>
> Thanks. But if you, Paul, make an incorrect assumption about what AS_IF really
> does, how many more users (who read only the documentation) will make the same
> mistake? I therefore think the documentation should be enhanced to avoid this
> misinterpretation.

I agree that this should be clarified; I just had the same
conversation in another thread. I'm not sure we should say AS_IF/CASE
are equivalent to plain shell if/case inside an AC_DEFUN; they do do
more than just make the m4 expansion stack not be empty.

Also, why is AS_FOR not documented? Maybe, instead of avoiding
mentioning it in NEWS, it should be documented?

zw

Re: autoconf-2.69c released [beta]

[Zack Weinberg]

On Sun, Sep 27, 2020 at 7:10 PM Bruno Haible  wrote:
>
> Paul Eggert wrote:
> > > I don't know where you got this magic number 301-14265 from.
> >
> > I got it by checking out the then-current commit of Autoconf from Savannah 
> > git,
> > and building from that.
> >
> > Presumably doing the right thing here would mean a fix to Autoconf's
> > m4_version_prereq macro, not to Gnulib. m4_version_prereq should do the 
> > right
> > thing for the per-commit version numbers that Autoconf itself uses.
>
> But m4_version_prereq can not know whether version 2.69.345 is before or
> after the prerelease 2.69e.
>
> I think the real fix is therefore to change the Autoconf build system
> so that instead of 2.69.301-14265 it would produce 2.69b.67-14265.
> Then m4_version_prereq would know that this was between 2.69b and 2.69c.
>
> Most probably either 'git-version-gen' or some use of 'git describe'
> can achieve this.

I just built autoconf (the program) from a completely clean checkout
of git trunk, which is currently two commits after the v2.69c tag, and
it identified itself as "autoconf (GNU Autoconf) 2.69c.2-04d14".  So
it appears to me that what you suggest, already happens.

However, then I checked out git commit
14265094af1614d9e359550ca4a4939e590a5dba and rebuilt the tree, and it
continued to identify itself as version 2.69c.2-04d14.  I had to run
`git clean -xdf` and re-autoreconf before it would start identifying
itself as 2.69b.67-14265.  So there *is* a bug somewhere in the build
process, where it fails to notice that the value of @VERSION@ ought to
change.  Perhaps that's how Paul got 2.69.301-14265.

zw

Re: Results from running autoupdate on gnulib m4 files

[Zack Weinberg]

On Sun, Sep 27, 2020 at 6:29 AM Gavin Smith  wrote:
> Because of the upcoming autoconf 2.70 release gives more warnings, I
> checked the other files in gnulib in the m4 directory with
>
> autoupdate -v *.m4 2>&1 | tee log

Thanks for doing this.  I was getting set up to do it myself, but I
got hung up on an unrelated problem (the version of "gettext" in
Debian is severely outdated and this makes it hard to run the gnulib
test suite).

The diff produced by autoupdate is mostly not usable as is.   In fact,
it looks to me more like a todo list for bugs and missing features in
autoupdate itself :-/  For instance, replacing
`AC_REQUIRE([AC_HEADER_STDC])` with `AC_REQUIRE([m4_warn([obsolete],
...])` is Just Plain Wrong, as is replacing `pushdef([AC_CHECKING],
[:])` with `pushdef([AS_MESSAGE([checking ...])],[:])`.

However, the change to m4/gethostname.m4 looks correct.

> * Redefinition of AC_CHECKING in several files to silence AC_CHECK_PROG

This was discussed previously at
https://lists.gnu.org/archive/html/bug-gnulib/2020-03/msg00032.html .
It remains my opinion that the correct fix is to convert all of these
to AC_CACHE_CHECK and not try to hide any checks from the person
running configure.

zw

Re: autoconf-2.69c released [beta]

[Zack Weinberg]

On Sat, Sep 26, 2020 at 8:15 AM Gavin Smith  wrote:
> On Fri, Sep 25, 2020 at 9:07 PM Gavin Smith  wrote:
> >
> > > * Warnings about obsolete constructs are now on by default.
> > >   They can be turned off with '-Wno-obsolete'.
> > >
> >
> > I have tried building the git development version of Texinfo with
> > the new autoconf, but am deluged with warnings.  I get the following
> > warnings from autoconf:
> >
> > configure.ac:87: warning: The macro `AC_GNU_SOURCE' is obsolete.
> > configure.ac:87: You should run autoupdate.
> > ./lib/autoconf/specific.m4:312: AC_GNU_SOURCE is expanded from...
> > gnulib/m4/gnulib-comp.m4:34: gl_EARLY is expanded from...
> > configure.ac:87: the top level
>
> I found it hard to track down where the AC_GNU_SOURCE use was coming
> from, and the path "lib/autoconf/specific.m4" is incorrect for the
> file "specific.m4".

Yes, unfortunately, the m4 backtrace emitted by configure warnings
doesn't handle AC_REQUIREd macros correctly.  Fixing this is probably
not feasible for 2.70.

> By searching for the text AC_GNU_SOURCE in all
> project files as well as installed autoconf files, as well as looking
> at the log files under autom4te.cache, I suspect it is coming from the
> "extensions.m4" file from Gnulib. (I don't know why that file isn't
> named in the error messages, though.) This has the following
> definition:
>
> # gl_USE_SYSTEM_EXTENSIONS
> # 
> # Enable extensions on systems that normally disable them,
> # typically due to standards-conformance issues.
> AC_DEFUN_ONCE([gl_USE_SYSTEM_EXTENSIONS],
> [
>   dnl Require this macro before AC_USE_SYSTEM_EXTENSIONS.
>   dnl gnulib does not need it. But if it gets required by third-party macros
>   dnl after AC_USE_SYSTEM_EXTENSIONS is required, autoconf 2.62..2.63 emit a
>   dnl warning: "AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS".
>   dnl Note: We can do this only for one of the macros AC_AIX, AC_GNU_SOURCE,
>   dnl AC_MINIX. If people still use AC_AIX or AC_MINIX, they are out of luck.
>   AC_REQUIRE([AC_GNU_SOURCE])
>
>   AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS])
> ])
>
> Would it be right to say that this should be changed in Gnulib,
> otherwise any project using that file with Gnulib will have errors
> from the new autoconf?

Yes, indeed.  All of the Gnulib and Autoconf Macro Archive macros need
to be checked for problems like this.  I'm cc:ing gnulib-bugs.

zw

Re: 32bit or LTO movemail build fails on macOS

[Zack Weinberg]

On Tue, Mar 24, 2020 at 10:58 PM Paul Eggert  wrote:
>
> Thanks for the bug report. Does the attached patch to getopt-pfx-core.h fix 
> the
> bug for you?
>
> I'll CC: this to bug-gnulib and to Zack Weinberg, who wrote that file. For 
> those
> new to this thread, please see <https://bugs.gnu.org/40205>.

Patch seems plausible enough to me.  I didn't think very hard about
the ways a system declaration of getopt could interfere when I wrote
this file.

zw

Re: debugging autoconf tests (was: gl_CACHE_VAL_SILENT)

[Zack Weinberg]

On Fri, Mar 13, 2020 at 10:49 PM Bruno Haible  wrote:
>> but when something goes
> > wrong, the poor schmuck who has to debug it wants to know that it was
> > the test for `ceil` (for instance) that hung the build, not the
> > unrelated thing that happens to have been tested right before that.
>
> Hanging autoconf tests are rare. And even in that case, looking at
> the configure output does not help much, because it won't tell you
> whether the compiler is taking hours or whether the test program hangs.
> In practice, when something hangs, "ps aux" or "pstree -p" (when available)
> is a better starting point for debugging.

Aha, you're coming at this from the perspective of debugging with
interactive access to the system where the problem happens.

All of the worst autoconf-related bugs I've had to deal with in the
past decade or so, showed up in CI environments that I did _not_ have
interactive access to.  I only got the transcript of the build.  I had
to specifically add code to dump the contents of config.log, and then
track things down further by adding extra AC_MSG_* within the problem
macro.  You can probably imagine how frustrating this can be,
especially when the cycle time is a half-hour or more.  I haven't had
to deal with any of these problems with a project that made heavy use
of gnulib, but I would have been quite annoyed to find that I was
barking up the wrong tree because configure didn't tell me that it was
doing some check because it didn't seem important enough.

Also, overriding $as_echo(_n), and your suggestion to override
AS_ECHO_N with pushdef, are more problematic than you may realize
because they affect what gets written to config.log, not just what
gets written to configure's stderr.  (Because configure writes to
config.log with a construct like AS_ECHO([...]) >&AS_MESSAGE_LOG_FD.)

May I suggest that what you really want is a --quiet switch for
configure, a la V=0 with automake-generated makefiles?  If you had
that, would you be OK with changing all of the gnulib .m4 files that
currently use gl_AC_CACHE_VAL_SILENT to use AC_CACHE_CHECK instead?

zw

Re: gl_CACHE_VAL_SILENT won't work correctly with upcoming autoconf 2.70

[Zack Weinberg]

On Fri, Mar 13, 2020 at 5:54 PM Bruno Haible  wrote:
>
> [CCing autoc...@gnu.org]
>
> Hi Zack,
>
> > Abstractly, the best thing to do about this would be to remove the
> > macro and change all of its uses to be AC_CACHE_CHECK, with proper
> > messaging, instead.
>
> The point is that we don't want messaging for some tests. Most people
> find the 'configure' output already long enough.

 I disagree with this on principle.  If you're doing any test that's
complicated enough to be worth caching, then you should use
AC_CACHE_CHECK and provide messaging for it.  Yeah, most of the time
that text is just going to scroll by unread, but when something goes
wrong, the poor schmuck who has to debug it wants to know that it was
the test for `ceil` (for instance) that hung the build, not the
unrelated thing that happens to have been tested right before that.

> The underlying problem in Autoconf is the following: There is a macro
> AC_CACHE_CHECK that does messaging, and a macro AC_CACHE_VAL whose
> main purpose is to make a cache lookup, not messaging, but it
> nevertheless outputs '(cached)' strings occasionally.

So based on the above my attitude is that AC_CACHE_VAL (and
AC_MSG_CHECKING and AC_MSG_RESULT) exist only for backward
compatibility's sake and what you're supposed to be using is
AC_CACHE_CHECK, and I'm not inclined to spend any of my own hacking
time on "a macro that is like AC_CACHE_VAL but produces no spurious
output".

On the other hand, if you write a patch and Paul or Eric likes it, I
won't stand in its way, either.

zw

gl_CACHE_VAL_SILENT won't work correctly with upcoming autoconf 2.70

[Zack Weinberg]

I'm doing groundwork for the long-overdue release of autoconf 2.70,
and part of that is checking to make sure that various changes in
development trunk since 2.69 haven't broken third-party macros.  I
noticed that gnulib-common.m4 contains a macro, gl_CACHE_VAL_SILENT,
that attempts to make AC_CACHE_VAL not print " (cached)" by changing
the value of the shell variable $as_echo_n.  This has had no effect
with development autoconf's AC_CACHE_VAL since 2013 (!)  and since,
um, today, it will also trigger -Wobsolete warnings.

Abstractly, the best thing to do about this would be to remove the
macro and change all of its uses to be AC_CACHE_CHECK, with proper
messaging, instead.  This would only not be possible if there was ever
a gl_CACHE_VAL_SILENT invocation *nested inside* an AC_CACHE_CHECK
invocation -- which shouldn't be done anyway, since the entire thing
would be skipped if the outer test is cached.  However, reviewing the
various uses, they are complicated enough that I don't think I am the
best person to write that patch.  I may still attempt it ...
eventually ... but I have a whole bunch of other work to do to make
the release possible, and this particular problem is mostly cosmetic.

zw

Re: [PATCH 1/1] Y2038: add function __difftime64

[Zack Weinberg]

On Thu, Jul 5, 2018 at 2:36 PM, Albert ARIBAUD  wrote:
> I have had a look at gnulib in the meantime, and I would like to know
> if the following assumptions are correct:

I can't comment on anything else at all, but:

> - gnulib does not contain any module which provides the time_t type, but
>   some of gnulib's modules assume there is such a type, and it might be
>   wider than 32 bits.
>
> - gnulib does not provide difftime either, so ATM a difftime patch
>   would only make sense in glibc, not gnulib.

 has always been required to declare a type named time_t and a
function named difftime, ever since the original C standard in 1989.
So it makes sense for gnulib not to provide either, and to assume they
exist.

In the original C standard time_t is only required to be "an
arithmetic type capable of representing times".  That means it could
be any size of integer or floating-point.   This has not changed as of
C11 -- the term "arithmetic type" changed to "real type" because of
the addition of complex numbers, but that's all.  POSIX adds the
additional guarantee that time_t is an integer type, but still says
nothing about how wide it is.

zw

Re: Sync gnulib regex with glibc

[Zack Weinberg]

On Thu, Dec 21, 2017 at 11:50 AM, Adhemerval Zanella
 wrote:
> The glibc testfile, bug-regex28.c, is related to BZ#3957 [1], which is not
> strictly related to RE_SYNTAX_{E}GREP definition. On gnulib side the change
> was done somewhat recently (2015) by 5a5a9388e.
>
> It does look like a correct change, but what I am worried from glibc
> standpoint is if it would require a compatibility implementation
> (potentially mapping RE_SYNTAX_{E}GREP to old definition on compat symbol).

I don't think that would actually help anything in this case. "This
program's embedded regexps are misinterpreted by a newer libc.so" is
not noticeably different from "This program's embedded regexps are
misinterpreted if the program has been recompiled with newer glibc".
Especially when it has to do with a corner case like whether . matches
\n.  Release notes are probably the best we can do here.

zw

Re: [PATCH 01/17] Regex: Fix spelling errors / typos.

[Zack Weinberg]

On Tue, Dec 19, 2017 at 2:03 PM Paul Eggert  wrote:

> These typo changes are all in Gnulib, and would be fine to install in
> glibc.
>
> Adding bug-gnulib to the CC list. For reference, the original email is
> here:
> https://sourceware.org/ml/libc-alpha/2017-12/msg00243.html


I don’t think Arnold has commit privileges for glibc, so, Paul, would you
mind going ahead and committing these approved patches for him? With
whatever adjustments  you feel are appropriate. I’m concerned that if they
aren’t landed now they will get lost in the shuffle.

(Off-list reply because I’m on my phone and can’t send text/plain.)

zw

> 

Re: [PING] [PATCH 00/17] Regex: Make libc regex more usable outside GLIBC

[Zack Weinberg]

On Tue, Dec 19, 2017 at 9:56 AM, Adhemerval Zanella
 wrote:
> On 19/12/2017 15:43, Paul Eggert wrote:
>> On 12/19/2017 04:52 AM, Adhemerval Zanella wrote:
>>> Again, my understanding is we still aim to keep it in sync with gnulib,
>>> so I think we should first integrate with current gnulib code on glibc
>>> side (in same approach as we did for current glob changes).
>>
>> As I understand it, Arnold's patches are against glibc. Arnold, would it be 
>> too much trouble to rebase them against gnulib instead? I could take a look 
>> at the result. I expect that many (most?) of these changes are already in 
>> Gnulib, so the result should be easier for you to generate than the original 
>> (and also be easier for me to review).

I agree that syncing first with gnulib is the way to go.  Also,
Arnold, I think you should be aware that glibc is coming up on a
release freeze, so reviewers' time is going to be focused on
higher-urgency stuff for the next month or so.  I will try to find
time to assist with these patches but it won't be till January.

zw

Re: getopt copyright header

[Zack Weinberg]

Sorry about that.  glibc's default copyright headers refer to the
library as a whole as being under the LGPL and it didn't occur to me
to check whether the gnulib policy is different.

On Fri, Oct 6, 2017 at 2:30 PM, Paul Eggert  wrote:
> Thanks, looks good to me.

Re: minus versus underscore in new getopt file names

[Zack Weinberg]

On Sun, Apr 9, 2017 at 4:06 AM, Paul Eggert  wrote:
> Zack Weinberg wrote:
>> I was being
>> consistent with the existing getopt_int.h - maybe that should be
>> renamed too?
>
> Maybe, but let's defer that as it's a separable change and it's to a
> longstanding file name. For now I just renamed the new files, using the
> attached Gnulib patch.

Do you think you could come up with matching patches for glibc?  For
this, and for the __nonnull thing.  I'm not going to have time this
week.

zw

Re: GNU LIB build fails on macOS 10.12.4

[Zack Weinberg]

> Please try the attached patch against Emacs master.
> If it works I plan to install it into Emacs and propagate
> it into Gnulib.

This patch is incomplete.  If gnulib cannot use __nonnull in
getopt_{core,ext}.h, then there is no point trying to define it in
getopt_cdefs.h.  And you're going to need to put snippet/arg-nonnull
back in the module file for this to work at all, aren't you?

>From glibc's point of view, I think it would be better if
getopt_core.h and getopt_ext.h simply assumed _GL_ARG_NONNULL to be
available; we can add it to either our getopt.h wrapper or to
sys/cdefs.h - I don't want to make that call unilaterally.  (Do you
know of a complete list of _GL_ macros that may appear in _public_
header files?)

zw

Re: minus versus underscore in new getopt file names

[Zack Weinberg]

On Sat, Apr 8, 2017 at 5:42 AM, Paul Eggert  wrote:
> Now that I think about it, the longstanding Gnulib and GNU tradition is to
> use minus in file names rather than underscore. How about if we rename the
> newly-introduced getopt source files to use minus instead of underscore?

I don't think glibc would have any objection to that.  I was being
consistent with the existing getopt_int.h - maybe that should be
renamed too?

zw

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

[Zack Weinberg]

On Thu, Apr 6, 2017 at 6:48 PM, Paul Eggert  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

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

[Zack Weinberg]

The implementation of 'getopt' is shared between gnulib and glibc, but
they have not been kept consistent in quite some time and there has
been quite a bit of divergence.  They also haven't really been
*maintained* in either project.

I set out simply to eliminate __need_getopt in both projects (see
previous discussion in threads at
https://sourceware.org/ml/libc-alpha/2017-03/msg00059.html,
https://sourceware.org/ml/libc-alpha/2017-03/msg00511.html, and
https://sourceware.org/ml/libc-alpha/2017-03/msg00512.html) but it
immediately became clear that a full bidirectional merge and quite a
few cleanups would be necessary to keep from going nuts.

Attached are a tarball of patches for glibc and a tarball of patches
for gnulib.  I apologize for making reviewers unpack them, but this
seemed the best way of preventing the patch-sets from getting mixed
up.  What they accomplish is:

 * getopt.c, getopt1.c, and getopt_int.h are now identical in both projects.
 * getopt.h has been exploded into many files.  The most important
two, getopt_core.h and getopt_ext.h, are also identical in both
projects.  The other two (in glibc) or four (in gnulib) are not shared
at all.
 * __need_getopt is eliminated.  In glibc, the replacement is #include
.  In gnulib it's slightly more complicated, see
unistd.in.h.

 * The code to handle _GNU_nonoption_argv_flags_ has been removed.
This was an experimental feature in bash 2.0.0, withdrawn in 2.0.1 and
never reconsidered.  All of the removed code has been ifdef-ed out
since 2001.
 * Error reporting in getopt.c no longer involves an #ifdef _LIBC
block for every single call to fprintf.
 * There is now only one copy of the code to process long options; an
off-by-one error in that code has been corrected, and memory-handling
while reporting ambiguous abbreviated options simplified.

Most of these changes should be completely invisible to applications.

zw


getopt-glibc.patchset.tar.gz
Description: GNU Zip compressed data


getopt-gnulib.patchset.tar.gz
Description: GNU Zip compressed data