Re: [PATCH] ifnames: Check for #elifdef and #elifndef

2024-06-15 Thread Paul Eggert
Thanks for the suggestion. I installed the attached more-elaborate 
patch, which also affects autom4te and autoscan.From 7feeafdf2f3e5bfe670b40994092d2e8ec5a536c Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 15 Jun 2024 08:24:05 -0700
Subject: [PATCH] Process C23 #elifdef and #elifndef
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Inspired by Collin Funk’s suggestion in:
https://lists.gnu.org/r/autoconf-patches/2024-06/msg0.html
* bin/autom4te.in (handle_output):
* bin/autoscan.in, bin/ifnames.in (scan_c_file):
Also recognize #elifdef and #elifndef.
* tests/tools.at (ifnames): Test it for ifnames.
---
 NEWS  | 6 ++
 bin/autom4te.in   | 4 ++--
 bin/autoscan.in   | 2 +-
 bin/ifnames.in| 9 +
 doc/autoconf.texi | 5 +++--
 tests/tools.at| 4 
 6 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/NEWS b/NEWS
index 521bbd3a..bca11391 100644
--- a/NEWS
+++ b/NEWS
@@ -22,6 +22,12 @@ GNU Autoconf NEWS - User visible changes.
   This reverts to Autoconf 2.69 behavior, and also fixes a bug where
   AC_PROG_CXX rejected C++20 compilers.
 
+** New features
+
+*** Programs now recognize #elifdef and #elifndef.
+  The autom4te, autoscan and ifnames programs now recognize the two
+  preprocessor directives, which were introduced in C23 and C++23.
+
 * Noteworthy changes in release 2.72 (2023-12-22) [release]
 
 ** Backward incompatibilities
diff --git a/bin/autom4te.in b/bin/autom4te.in
index e9fa1886..48377cb9 100644
--- a/bin/autom4te.in
+++ b/bin/autom4te.in
@@ -636,7 +636,7 @@ sub handle_output ($$)
   # Don't complain in comments.  Well, until we have something
   # better, don't consider '#include' etc. are comments.
   s/\#.*//
-	unless /^\#\s*(if|include|endif|ifdef|ifndef|define)\b/;
+	unless /^\#\s*(include|endif|(el)?if(n?def)?|define)\b/;
   foreach (split (/\W+/))
 	{
 	  $prohibited{$_} = $.
@@ -673,7 +673,7 @@ sub handle_output ($$)
 	  # Don't complain in comments.  Well, until we have something
 	  # better, don't consider '#include' etc. to be comments.
 	  s/\#.*//
-	unless /^\#(if|include|endif|ifdef|ifndef|define)\b/;
+	unless /^\#(include|endif|(el)?if(n?def)?|define)\b/;
 
 	  # Complain once per word, but possibly several times per line.
 	  while (/$prohibited/)
diff --git a/bin/autoscan.in b/bin/autoscan.in
index 5072f80c..542865a9 100644
--- a/bin/autoscan.in
+++ b/bin/autoscan.in
@@ -276,7 +276,7 @@ sub scan_c_file ($)
 	{
 	  used ('header', $1);
 	}
-	  if (s/^(if|ifdef|ifndef|elif)\s+//)
+	  if (s/^(el)?if(n?def)?\s+//)
 	{
 	  foreach my $word (split (/\W+/))
 		{
diff --git a/bin/ifnames.in b/bin/ifnames.in
index c0c5f611..59a3d131 100644
--- a/bin/ifnames.in
+++ b/bin/ifnames.in
@@ -55,9 +55,10 @@ $help = "Usage: $0 [OPTION]... [FILE]...
 
 Scan all of the C source FILES (or the standard input, if none are
 given) and write to the standard output a sorted list of all the
-identifiers that appear in those files in '#if', '#elif', '#ifdef', or
-'#ifndef' directives.  Print each identifier on a line, followed by a
-space-separated list of the files in which that identifier occurs.
+identifiers that appear in those files in '#if', '#ifdef', '#ifndef',
+'#elif', '#elifdef', or '#elifndef' directives.  Print each identifier
+on a line, followed by a space-separated list of the files in which
+that identifier occurs.
 
   -h, --help  print this help, then exit
   -V, --version   print version number, then exit
@@ -109,7 +110,7 @@ sub scan_file ($)
 	while (s/\\$//);
 
   # Preprocessor directives.
-  if (s/^\s*\#\s*(if|ifdef|ifndef|elif)\s+//)
+  if (s/^\s*\#\s*(el)?if(n?def)?\s+//)
 	{
 	  # Remove comments.  Not perfect, but close enough.
 	  s(/\*.*?\*/)();
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 9c05ecee..832858cf 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -1478,8 +1478,9 @@ Invocation}).
 @command{ifnames} scans all of the C source files named on the command line
 (or the standard input, if none are given) and writes to the standard
 output a sorted list of all the identifiers that appear in those files
-in @code{#if}, @code{#elif}, @code{#ifdef}, or @code{#ifndef}
-directives.  It prints each identifier on a line, followed by a
+in @code{#if}, @code{#ifdef}, @code{#ifndef}, @code{#elif},
+@code{#elifdef}, or @code{#elifndef} directives.
+It prints each identifier on a line, followed by a
 space-separated list of the files in which that identifier occurs.
 
 @noindent
diff --git a/tests/tools.at b/tests/tools.at
index 37fe1466..867ecd68 100644
--- a/tests/tools.at
+++ b/tests/tools.at
@@ -732,6 +732,8 @@ LINE2
 
 AT_DATA([iftest2.c],
 [[#ifdef IFTEST2
+#elifdef IFTEST3
+#elifndef IFTEST4
 #if VAL1
 ]])
 
@@ -741,6 +743,8 @@ DEF2 iftest1.c
 DEF3 iftest1.c
 DEF4 iftest1.c
 IFTEST2 iftest2.c
+IFTEST3 iftest2.c
+IFTEST4 iftest2.c
 LINE1 iftest1.c
 LINE2 iftest1.c
 SPACES iftest1.c
-- 
2.43.0



Re: [PATCH] Add quotes in AS_IF test for gid_t

2024-02-07 Thread Paul Eggert

On 2/6/24 20:37, Nick Bowler wrote:

On 2024-02-06 22:33, Sam James wrote:

Noticed when building Emacs:
```
* checking type of array argument to getgroups... ./configure: 42782: test: =: 
unexpected operator
```



Oh look, I see this line in emacs-29.2/configure.ac:

   AC_DEFUN([AC_TYPE_UID_T])

This is the actual cause of the problem, because AC_TYPE_UID_T is the
part of Autoconf that would have assigned this variable.  Since Emacs
has deleted its definition, it has therefore broken other Autoconf
macros (like AC_TYPE_GETGROUPS) which depend on it.


Thanks for reporting this. I installed the attached patch into Emacs master.

The now-fixed bug in Emacs's generated 'configure' script should be 
harmless on all platforms I know about, as AC_TYPE_GETGROUPS should go 
ahead and do the right thing anyway.


PS. There is a case for quoting all uses of ac_cv_* variables, as their 
values may be corrupted in the cache. This is my usual style elsewhere 
and perhaps Autoconf should adopt it. Of course if we'd done that we 
would likely never have spotted this harmless error in Emacs 
configure.acFrom e34ebc0ccc6c27e7e1217baad9ca74dd7bea4c37 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Wed, 7 Feb 2024 13:17:57 -0800
Subject: [PATCH] Port better to Autoconf 2.72

* configure.ac: Set ac_cv_type_gid_t=yes to pacify Autoconf 2.72
AC_TYPE_GETGROUPS.  Problem reported by Nick Bowler in:
https://lists.gnu.org/r/autoconf-patches/2024-02/msg1.html
---
 configure.ac | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure.ac b/configure.ac
index b74eba879ab..847fdbd54d2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2337,6 +2337,7 @@ AC_DEFUN
 AC_DEFUN([AC_TYPE_SIZE_T])
 # Likewise for obsolescent test for uid_t, gid_t; Emacs assumes them.
 AC_DEFUN([AC_TYPE_UID_T])
+ac_cv_type_gid_t=yes # AC_TYPE_GETGROUPS needs this in Autoconf 2.72.
 
 # Check for all math.h functions that Emacs uses; on some platforms,
 # -lm is needed for some of these functions.
-- 
2.43.0



Re: [PATCH] Add quotes in AS_IF test for gid_t

2024-02-06 Thread Paul Eggert

On 2024-02-06 20:37, Nick Bowler wrote:

The right place to fix this problem is in Emacs.


I don't see this problem in current (bleeding-edge Savannah) Emacs. Sam, 
which Emacs are you talking about?




Re: [PATCH] [committed] autom4te: Don’t crash if Data::Dumper::Sortkeys is unavailable.

2023-12-19 Thread Paul Eggert

On 2023-12-11 13:48, Paul Eggert wrote:

On 12/11/23 10:19, Zack Weinberg wrote:

we lowered it to 5.6.0
again in 05e295b60cfdf378b7ed8c1f8563a5644d5d4689


A minor point: in that commit message I mentioned that Solaris 10 (which 
has only Perl 5.8.4) was supported through January 2024. On that same 
day (!) Oracle announced[1] that they were extending Solaris's 10 EOL to 
January 2025

... and they've extended it again, this time to January 2027:

https://blogs.oracle.com/solaris/post/new-end-date-of-extended-support-for-oracle-solaris-10-and-113

Solaris 10: the OS version that refuses to die



Re: [PATCH] [committed] autom4te: Don’t crash if Data::Dumper::Sortkeys is unavailable.

2023-12-11 Thread Paul Eggert

On 12/11/23 10:19, Zack Weinberg wrote:

we lowered it to 5.6.0
again in 05e295b60cfdf378b7ed8c1f8563a5644d5d4689


A minor point: in that commit message I mentioned that Solaris 10 (which 
has only Perl 5.8.4) was supported through January 2024. On that same 
day (!) Oracle announced[1] that they were extending Solaris's 10 EOL to 
January 2025. So, since Solaris is the last holdout we know of, Autoconf 
should be able to start requiring Perl 5.10 starting February 2025, if 
it's helpful to do so.


[1]: 
https://blogs.oracle.com/support/post/extended-support-for-oracle-solaris-10-operating-system




Re: [PATCH 2/2] Ignore failure of setting mode on a temporary file on OS/2

2023-10-17 Thread Paul Eggert

On 10/17/23 11:16, Zack Weinberg wrote:

On Sun, Oct 15, 2023, at 3:43 AM, KO Myung-Hun wrote:

How about this ?
1. create and close a temporary file
2. chmod() on it
3. re-open it with O_TRUNC ?


The trouble is, on a multi-user system, any time you do any operation
by name on a file whose full pathname includes a world-writable
directory (such as the system-wide scratch directories), even if that
directory is “sticky” (chmod +t), you have to be exquisitely careful,
or a malicious concurrent process might be able to trick you into
overwriting some file elsewhere on the filesystem.  For example, your
steps 2 and 3, if executed as root on a file expected to exist in
/tmp, would give a malicious concurrent process a chance to clobber
the access control bits and/or the contents of *any file*, by moving
the temporary file out of the way


? If /tmp is sticky, a malicious process can't rename /tmp/foo.

The rest of your email and patch look good to me, though admittedly I 
haven't used perl for real in 30 years.





Re: How to get autoconf to respect CC="gcc -std=c89"?

2023-10-07 Thread Paul Eggert

On 2023-10-07 02:03, Niels Möller wrote:
there's some impedance mismatch between the whitespace separated list to 
AC_C_STANDARD_VERSION, and the comma-separated list required by m4_map


Yes, let's use the same list style for both.



Re: How to get autoconf to respect CC="gcc -std=c89"?

2023-10-06 Thread Paul Eggert

Thanks for looking into this.

Some comments.

This doesn't let you say "I want either c89 or c99, but not c11".


+  m4_ifdef([_AC_C_STANDARD_VERSION_LIST],
+[m4_fatal([AC_PROG_C_STANDARD_VERSION should only be used once], 1)])


Why have this check?

How about something simpler, like replacing this:

m4_map([_AC_PROG_CC_STDC_EDITION_TRY], [[11], [99], [89]])])

with this:

m4_map([_AC_PROG_CC_STDC_EDITION_TRY],
  [m4_default([_AC_C_STANDARD_VERSION_LIST],
 [[11], [99], [89]])])

and not bothering to check for allowed or duplicated version lists?



Re: [PATCH] Fix _AC_LANG_IO_PROGRAM(C) to work with glibc 2.38 headers

2023-08-15 Thread Paul Eggert

Thanks, I installed that.



Re: INSTALL updates

2023-06-24 Thread Paul Eggert

On 2023-06-23 08:42, Bruno Haible wrote:

Find here a proposed patch.


Thanks, I installed that into Autoconf. The result was a bit long for 
INSTALL (partly because of the new sections, which were a pain for the 
Autoconf manual proper) so I pruned and otherwise improved it, mostly by 
rewording and reordering and coalescing sections, but also by omitting 
some rarely used options like --target. I installed the attached further 
patch into Autoconf and propagated this into Gnulib.


Amusingly enough, my effort was prompted by a single line in your patch:

Invalid configuration `crusoe-linux': machine `crusoe-unknown' not 
recognized


which was a bit long for .info, plus those grave accents should be 
apostrophes. I arranged for config.sub to generate apostrophes rather 
than grave accents by sending a bug report to the config project, and 
this has been propagated into Gnulib as well so those grave accents are 
gone. While I was at it I ended up rewriting the other stuff.From d8ca8b323873e5cd9d969a062f70b31db450ba53 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 24 Jun 2023 14:39:34 -0700
Subject: [PATCH] Shorten and improve INSTALL
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Rewrite install.texi so that INSTALL is shorter and hopefully
more useful for new installers.
* doc/install.texi: When not building the Autoconf manual, put
copyright notice at the end, and omit external references as they
do not work in INSTALL.
Avoid long URLs as they do not work well in INSTALL or
in info files.  Be more consistent (though not entirely
consistent) about “system” vs “architecture”.
(System Types, Building for a different system type)
(Troubleshooting the Build Type): Coalesce into a single section
and rewrite for clarity and brevity.  Mention build-aux.  Do not
mention --target here as it’s too rare to make the cut.
---
 doc/install.texi | 224 +--
 1 file changed, 82 insertions(+), 142 deletions(-)

diff --git a/doc/install.texi b/doc/install.texi
index a3ef1782..6c3a9c21 100644
--- a/doc/install.texi
+++ b/doc/install.texi
@@ -2,23 +2,13 @@
 @c the INSTALL file.
 
 @ifclear autoconf
-
 @unnumbered Installation Instructions
-
-Copyright @copyright{} 1994--1996, 1999--2002, 2004--2017, 2020--2023
-Free Software Foundation, Inc.
-
-Copying and distribution of this file, with or without modification, are
-permitted in any medium without royalty provided the copyright notice
-and this notice are preserved.  This file is offered as-is, without
-warranty of any kind.
-
 @end ifclear
 
 @node Basic Installation
 @section Basic Installation
 
-Briefly, the following shell commands:
+The following shell commands:
 
 @example
 test -f configure || ./bootstrap
@@ -41,8 +31,13 @@ of the features documented below.  The lack of an optional feature in a
 given package is not necessarily a bug.
 @end ifclear
 More recommendations for GNU packages can be found in
+@ifset autoconf
 @ref{Makefile Conventions, , Makefile Conventions, standards,
 GNU Coding Standards}.
+@end ifset
+@ifclear autoconf
+the GNU Coding Standards.
+@end ifclear
 
 If the @command{bootstrap} shell script exists, it attempts to build the
 @command{configure} shell script and related files, perhaps by
@@ -61,8 +56,8 @@ those values to create a @file{Makefile} in each directory of the
 package.  It may also create one or more @file{.h} files containing
 system-dependent definitions.  Finally, it creates a shell script
 @file{config.status} that you can run in the future to recreate the
-current configuration, and a file @file{config.log} containing compiler
-output (useful mainly for debugging @command{configure}).
+current configuration, and a file @file{config.log} containing
+output useful for debugging @command{configure}.
 
 It can also use an optional file (typically called @file{config.cache}
 and enabled with @option{--cache-file=config.cache} or simply
@@ -77,10 +72,9 @@ they can be considered for the next release.  If you are using the
 cache, and at some point @file{config.cache} contains results you don't
 want to keep, you may remove or edit it.
 
-The file @file{configure.ac} (or @file{configure.in}) is used to create
-@file{configure} by a program called @command{autoconf}.  You need
-@file{configure.ac} if you want to change it or regenerate
-@file{configure} using a newer version of @command{autoconf}.
+The @command{autoconf} program generates @file{configure} from the file
+@file{configure.ac}.  Normally you should edit @file{configure.ac}
+instead of editing @file{configure} directly.
 
 The simplest way to compile this package is:
 
@@ -95,8 +89,7 @@ You may need special developer tools and network access to bootstrap.
 
 @item
 Type @samp{./configure} to configure the package for your system.
-
-Running @command{configure} might take a while.  While running, it prints some
+This might take a while.  While running, @co

Re: Document limitation of BusyBox tr

2023-04-17 Thread Paul Eggert

Thanks, I installed that 2023-03-03 doc patch into Autoconf master.



Re: patchset v2: remove remaining internal uses of AC_EGREP_{CPP,HEADER}

2023-04-02 Thread Paul Eggert

Thanks, I took a quick look at all the patches and see no issues.



Re: RFC PATCH: Overhaul AC_TYPE_GETGROUPS and AC_FUNC_GETGROUPS.

2023-04-02 Thread Paul Eggert

On 2023-04-02 18:30, Zack Weinberg wrote:

how about I revise this patch to remove the case for
freebsd* | darwin*, and make no other changes?


Yes, sounds good, thanks.



Re: RFC PATCH: Overhaul AC_TYPE_GETGROUPS and AC_FUNC_GETGROUPS.

2023-04-02 Thread Paul Eggert

On 2023-04-02 12:42, Zack Weinberg wrote:


Cross-referencing gnulib’s getgroups.m4 I see that there *are*
current-generation Unixes with bugs in getgroups that are worth
worrying about (notably, FreeBSD mishandles an error case even in
CURRENT). 


That error case is not very important, as calling getgroups with a 
negative size) since programs are not likely to exercise it. The really 
serious failures are for long-dead systems (Ultrix 4.3, NextSTEP 3.2) 
that we no longer need to worry about.


AC_FUNC_GETGROUPS has been documented as being obsolescent since 
Autoconf 2.70 (2020). I think changing it to report a failure on macOS 
and FreeBSD is more likely to cause problems than cure them. So I 
instead that we instead either leave it alone, or merely add an 
obsoletion notice, or (if we want to be more dramatic) replace it with 
something that merely tests whether the function has the correct 
prototype and links properly.





Re: time for Autoconf 2.72 (was: On time64 and Large File Support)

2023-03-17 Thread Paul Eggert

On 3/17/23 19:08, Jim Meyering wrote:

Can someone see if there's some small/safe set of changes that are essential?
If none (or few/easy), I might have time to make a snapshot soon.


As far as I know, none of the pending patches are essential and we can 
release what we have.




Re: time for Autoconf 2.72 (was: On time64 and Large File Support)

2023-03-17 Thread Paul Eggert

On 3/17/23 16:47, Sam James wrote:

Clang 16 was released today. Unfortunately, all released versions of
autoconf still generate configure scripts which are incompatible with it.


Presumably "./configure CC='clang -std=gnu17" is a workaround, though 
admittedly this is awkward.



Is anyone aware of any issues with master as it is? I've been running
with it for months.


Thanks for the info. I've been too swamped to shepherd a release, 
unfortunately. But we should do one soon.




Re: Add vendor configuration directory installation

2023-02-07 Thread Paul Eggert

On 2023-02-06 08:30, Valentin Lefebvre wrote:

 This patch add a new autoconf argument that allows installation
into the vendor configuration directory (/usr/etc/). Some linux
distribution now move system configuration files from /etc to /usr/etc.
See this ref: [0]



[0]https://0pointer.net/blog/projects/stateless.html


I don't see "/usr/etc" in [0]. What I see is /usr/share/etc, i.e., 
$(datarootdir)/etc. It's not clear why the latter name doesn't suffice 
for this need, as files in $(datarootdir) are also supplied by the 
distro and are read-only.


Also, make-stds.texi and standards.texi are upstream from Autoconf; to 
make changes to them, please email bug-standa...@gnu.org. I'll cc this 
to that email address to give them a heads-up.




time for Autoconf 2.72 (was: On time64 and Large File Support)

2023-02-02 Thread Paul Eggert

On 2/1/23 22:43, Sam James wrote:

Unfortunately, I think we've missed the Debian freeze I think, but it is what 
it is there
(was hoping to get it in there so we could benefit from the large number of 
people who make dist tarballs on Debian).


Oh well. As you say, it is what it is.

Since there's been no comment about that documentation change I 
installed it in Autoconf master on Savannah. I also installed the result 
of a 'make fetch'.


As far as I know, the next Autoconf release is good to go. Unfortunately 
I can't test Autoconf as well as Zack tested it. However, it appears 
that releasing what we've got would be better than not releasing it so 
I'm hoping that we can release Autoconf 2.72 soon, even if it's not as 
well tested as Autoconf 2.71 was.


Comments welcome.



Re: On time64 and Large File Support

2023-01-20 Thread Paul Eggert

On 2022-12-30 14:12, Paul Eggert wrote:
I'm attaching a proposed patch to Autoconf master documentation in two 
forms.
Zack, any further thoughts on that Autoconf patch? If not, I'm inclined 
to install it as it doesn't change behavior, only documentation, and Sam 
wrote that he was happy with the patch. For convenience I'm reattaching 
the same patch to this email.


Also, is there anything else blocking a new Autoconf release?From 3e9f1159ae9145c50d048a74422dd8464a6a8f6f Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Fri, 30 Dec 2022 12:48:39 -0800
Subject: [PATCH] Improve year-2038 documentation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* NEWS, doc/autoconf.texi (System Services):
Improve documentation for behavior of largefile and year-2038 support.
Say that in the current implementation, year-2038 support
requires largefile support.  Say that year-2038 support
matters only for GNU/Linux glibc 2.34+ on 32-bit x86 and ARM.
Prefer brevity when this does not hurt understandability;
for example, prefer active to passive voice.
Prefer “wider” to “larger” when talking about the number of
bits in an integer, as this terminology is more standard.
Tone down the wording in warnings about enabling year-2038 support,
use similar wording in warnings about enabling largefile support,
and warn also about disabling largefile and year-2038 support.
No need for @emph.  Also mention rlim_t.
Be a bit more careful about saying “2 GiB” rather than “2 GB”.
Mention that a future version of Autoconf might change
AC_SYS_LARGEFILE to default to --enable-year2038, since
something has gotta happen before 2038.
Coalesce descriptions of --enable-largefile and --enable-year2038
to simplify documentation.  Mention that the only system where
AC_SYS_LARGEFILE changes CC is IRIX and that these systems
are obsolete.  Say that ‘stat’ can fail due to time_t
overflow.  Say that you can’t portably print time_t with %ld.
Say that binary compatibilty problems also can occur when one
library is linking to amother; it’s not just apps vs libraries.
Mention the possibility of modifying libraries to support both
32- and 64-bit interfaces.  Warn more consistently about
ABI compatibility issues, but put the bulk of this text
in one location that the other locations refer to.
---
 NEWS  |  57 
 doc/autoconf.texi | 165 --
 2 files changed, 113 insertions(+), 109 deletions(-)

diff --git a/NEWS b/NEWS
index eafd7d69..0f71628d 100644
--- a/NEWS
+++ b/NEWS
@@ -27,36 +27,33 @@ GNU Autoconf NEWS - User visible changes.
 
 ** New features
 
-*** New macros AC_SYS_YEAR2038 and AC_SYS_YEAR2038_REQUIRED.
-  These macros attempt to enlarge time_t to 64 bits, on systems where
-  it has historically been only 32 bits wide, and therefore (assuming
-  the usual Unix epoch) cannot represent dates after mid-January of
-  2038 (hence the names).  The difference between the two is that
-  AC_SYS_YEAR2038_REQUIRED unconditionally causes 'configure' to error
-  out if 64-bit time_t is not available.
-
-  Enlarging time_t to 64 bits is likely to have the side effect of
-  enlarging off_t and related types to 64 bits as well, as if you
-  had used AC_SYS_LARGEFILE.  See the manual for details.
-
-  Library authors should be cautious about adding these macros to
-  their configure scripts; they can break binary backward compatibility.
-
-*** New macro AC_SYS_LARGEFILE_REQUIRED.
-  This macro is the same as the existing AC_SYS_LARGEFILE except that
-  it will cause 'configure' to error out if 64-bit off_t is not available,
-  and it does not provide a --disable-largefile option.
-
-*** AC_SYS_LARGEFILE now optionally arranges to enlarge time_t.
-  As an experimental measure to make it easier to rebuild old programs
-  with support for dates after Jan 2038, if you regenerate any configure
-  script that uses AC_SYS_LARGEFILE (but not AC_SYS_YEAR2038) using
-  Autoconf 2.72, it will gain an --enable-year2038 option.  When the
-  program is configured with this option, time_t will be enlarged if
-  possible, as if AC_SYS_YEAR2038 had been used.
-
-  Using this option in a library build also potentially breaks binary
-  backward compatibility.
+*** New macro AC_SYS_YEAR2038.
+  This causes 'configure' to widen time_t if possible on systems where
+  time_t by default cannot represent file and other timestamps after
+  January 2038.  Widening is possible only on 32-bit GNU/Linux x86 and
+  ARM systems with glibc 2.34 or later.  To prevent widening,
+  configure with --disable-year2038.
+
+  This macro also has the effects as AC_SYS_LARGEFILE, because in
+  practice time_t cannot be widened without large-file sypport.
+
+  Application and library builders should take care that packages
+  configured with --enable-year2038 and --disable-year2038 options
+  are configured consistently, to avoid breaking binary

Re: On time64 and Large File Support

2022-12-30 Thread Paul Eggert
 plan. 
Given the long delay between Autoconf versions and end uses of 
downstream software, we need a plan now, not years from now. The plan 
doesn't have to be perfect, nor does it need to be cast in stone. But 
there needs to be a plan.
From 3e9f1159ae9145c50d048a74422dd8464a6a8f6f Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Fri, 30 Dec 2022 12:48:39 -0800
Subject: [PATCH] Improve year-2038 documentation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* NEWS, doc/autoconf.texi (System Services):
Improve documentation for behavior of largefile and year-2038 support.
Say that in the current implementation, year-2038 support
requires largefile support.  Say that year-2038 support
matters only for GNU/Linux glibc 2.34+ on 32-bit x86 and ARM.
Prefer brevity when this does not hurt understandability;
for example, prefer active to passive voice.
Prefer “wider” to “larger” when talking about the number of
bits in an integer, as this terminology is more standard.
Tone down the wording in warnings about enabling year-2038 support,
use similar wording in warnings about enabling largefile support,
and warn also about disabling largefile and year-2038 support.
No need for @emph.  Also mention rlim_t.
Be a bit more careful about saying “2 GiB” rather than “2 GB”.
Mention that a future version of Autoconf might change
AC_SYS_LARGEFILE to default to --enable-year2038, since
something has gotta happen before 2038.
Coalesce descriptions of --enable-largefile and --enable-year2038
to simplify documentation.  Mention that the only system where
AC_SYS_LARGEFILE changes CC is IRIX and that these systems
are obsolete.  Say that ‘stat’ can fail due to time_t
overflow.  Say that you can’t portably print time_t with %ld.
Say that binary compatibilty problems also can occur when one
library is linking to amother; it’s not just apps vs libraries.
Mention the possibility of modifying libraries to support both
32- and 64-bit interfaces.  Warn more consistently about
ABI compatibility issues, but put the bulk of this text
in one location that the other locations refer to.
---
 NEWS  |  57 
 doc/autoconf.texi | 165 --
 2 files changed, 113 insertions(+), 109 deletions(-)

diff --git a/NEWS b/NEWS
index eafd7d69..0f71628d 100644
--- a/NEWS
+++ b/NEWS
@@ -27,36 +27,33 @@ GNU Autoconf NEWS - User visible changes.
 
 ** New features
 
-*** New macros AC_SYS_YEAR2038 and AC_SYS_YEAR2038_REQUIRED.
-  These macros attempt to enlarge time_t to 64 bits, on systems where
-  it has historically been only 32 bits wide, and therefore (assuming
-  the usual Unix epoch) cannot represent dates after mid-January of
-  2038 (hence the names).  The difference between the two is that
-  AC_SYS_YEAR2038_REQUIRED unconditionally causes 'configure' to error
-  out if 64-bit time_t is not available.
-
-  Enlarging time_t to 64 bits is likely to have the side effect of
-  enlarging off_t and related types to 64 bits as well, as if you
-  had used AC_SYS_LARGEFILE.  See the manual for details.
-
-  Library authors should be cautious about adding these macros to
-  their configure scripts; they can break binary backward compatibility.
-
-*** New macro AC_SYS_LARGEFILE_REQUIRED.
-  This macro is the same as the existing AC_SYS_LARGEFILE except that
-  it will cause 'configure' to error out if 64-bit off_t is not available,
-  and it does not provide a --disable-largefile option.
-
-*** AC_SYS_LARGEFILE now optionally arranges to enlarge time_t.
-  As an experimental measure to make it easier to rebuild old programs
-  with support for dates after Jan 2038, if you regenerate any configure
-  script that uses AC_SYS_LARGEFILE (but not AC_SYS_YEAR2038) using
-  Autoconf 2.72, it will gain an --enable-year2038 option.  When the
-  program is configured with this option, time_t will be enlarged if
-  possible, as if AC_SYS_YEAR2038 had been used.
-
-  Using this option in a library build also potentially breaks binary
-  backward compatibility.
+*** New macro AC_SYS_YEAR2038.
+  This causes 'configure' to widen time_t if possible on systems where
+  time_t by default cannot represent file and other timestamps after
+  January 2038.  Widening is possible only on 32-bit GNU/Linux x86 and
+  ARM systems with glibc 2.34 or later.  To prevent widening,
+  configure with --disable-year2038.
+
+  This macro also has the effects as AC_SYS_LARGEFILE, because in
+  practice time_t cannot be widened without large-file sypport.
+
+  Application and library builders should take care that packages
+  configured with --enable-year2038 and --disable-year2038 options
+  are configured consistently, to avoid breaking binary compatibility.
+  This is similar to longstanding consistency requirements with
+  --enable-largefile and --disable-largefile.
+
+*** AC_SYS_LARGEFILE now optionally arranges to widen time_t.
+  It now acts like 

Re: On time64 and Large File Support

2022-12-25 Thread Paul Eggert

On 11/12/22 21:11, Zack Weinberg wrote:

"A couple hours" more like eight, ugh.


I know the feeling. I didn't get time free until recently.

I reviewed your patch and had the following thoughts.

* Gnulib doesn't need AC_SYS_LARGEFILE_REQUIRED or 
AC_SYS_YEAR2038_REQUIRED and they're easy for users to do on their own 
with a simple AS_IF, so let's omit these variants for now, to keep 
things simpler.


* The documentation incorrectly implies that AC_SYS_LARGEFILE and 
AC_SYS_YEAR2038 are orthogonal, i.e., that one can request large-file 
support and year-2038 support independently. But AC_SYS_YEAR2038 
AC_REQUIREs AC_SYS_LARGEFILE, and one cannot configure with 
--disable-largefile --enable-year2038 and expect things to work. This is 
inherent to the underlying _TIME_BITS mechanism; it's not something 
Autoconf can fix with glibc, and since this year-2038 business only 
occurs with glibc it's not something Autoconf can (or is likely to be 
able to) fix anywhere.


To help things move forward I installed your patch into Autoconf master 
on Savannah, and followed up with the attached patch which tries to 
address the above issues. In particular, it notes that the difference 
between AC_SYS_LARGEFILE and AC_SYS_YEAR2038 is a temporary hack, in 
that eventually (hopefully well before the year 2038) AC_SYS_LARGEFILE 
will be an alias for what AC_SYS_YEAR2038 does now.


Comments welcome of course.

I tested this by migrating these Autoconf changes into my private copy 
of Gnulib and gzip, and building gzip on both 32- and 64-bit glibc. I 
plan to install those changes on Savannah soon, and to follow up with 
similar changes to GNU coreutils etc. This should help to test these 
Autoconf changes before the next Autoconf is released.
From 3f3354507bb9c2f1d38412cf566ff9443408023e Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 24 Dec 2022 23:24:54 -0800
Subject: [PATCH] Omit just-added *_REQUIRED macros

They are not needed for Gnulib, and users have an easy way to get
their effect, so for now omit them and just document the easy way.
Also, redo documentation to make it clear that AC_YEAR_2038 is
like AC_SYS_LARGEFILE except with a different year-2038 default.
* NEWS, doc/autoconf.texi: Document the above.
* lib/autoconf/specific.m4 (AC_SYS_YEAR2038_REQUIRED):
(AC_SYS_LARGEFILE_REQUIRED): Remove.  Remove some support code.
Perhaps further simplification could be done but I quit while
I was ahead.
---
 NEWS |  43 +++--
 doc/autoconf.texi| 185 +--
 lib/autoconf/specific.m4 |  65 +++---
 3 files changed, 104 insertions(+), 189 deletions(-)

diff --git a/NEWS b/NEWS
index d9c6ed94..5e8a7606 100644
--- a/NEWS
+++ b/NEWS
@@ -27,37 +27,18 @@ GNU Autoconf NEWS - User visible changes.
 
 ** New features
 
-*** New macros AC_SYS_YEAR2038 and AC_SYS_YEAR2038_REQUIRED.
-  These macros attempt to enlarge time_t to 64 bits, on systems where
-  it has historically been only 32 bits wide, and therefore (assuming
-  the usual Unix epoch) cannot represent dates after mid-January of
-  2038 (hence the names).  The difference between the two is that
-  AC_SYS_YEAR2038_REQUIRED unconditionally causes 'configure' to error
-  out if 64-bit time_t is not available.
-
-  AC_SYS_YEAR2038 will also error out if the host system shows signs of
-  supporting dates after Jan 2038 (e.g. in file timestamps) but it can’t
-  figure out how to get a wider time_t; this failure can be overridden
-  with the --disable-year2038 option.
-
-  Library authors should be cautious about adding these macros to
-  their configure scripts; they can break binary backward compatibility.
-
-*** New macro AC_SYS_LARGEFILE_REQUIRED.
-  This macro is the same as the existing AC_SYS_LARGEFILE except that
-  it will cause 'configure' to error out if 64-bit off_t is not available,
-  and it does not provide a --disable-largefile option.
-
-*** AC_SYS_LARGEFILE now optionally arranges to enlarge time_t.
-  As an experimental measure to make it easier to rebuild old programs
-  with support for dates after Jan 2038, if you regenerate any configure
-  script that uses AC_SYS_LARGEFILE (but not AC_SYS_YEAR2038) using
-  Autoconf 2.72, it will gain an --enable-year2038 option.  When the
-  program is configured with this option, time_t will be enlarged if
-  possible, as if AC_SYS_YEAR2038 had been used.
-
-  Using this option in a library build also potentially breaks binary
-  backward compatibility.
+*** AC_SYS_LARGEFILE now optionally arranges to widen time_t.
+  It now causes 'configure' to gain an --enable-year2038 option which
+  widens time_t if possible on systems where time_t by default cannot
+  represent file timestamps and other timestamps after January 2038.
+  As with off_t, ino_t, etc., if library ABIs depend on time_t width,
+  applications should be configured consistently with libraries.
+
+*** New mac

[committed 2/3] Use UTF-8 and spell "François" correctly

2022-12-24 Thread Paul Eggert
inard, Karl Berry, Richard Pixley, Ian Lance Taylor,
+# François Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
 # Roland McGrath, Noah Friedman, david d zuhn, and many others.
 
 
diff --git a/lib/autoconf/autotest.m4 b/lib/autoconf/autotest.m4
index 40383c09..bb7f6ff3 100644
--- a/lib/autoconf/autotest.m4
+++ b/lib/autoconf/autotest.m4
@@ -24,7 +24,7 @@
 # respectively.  If not, see <https://www.gnu.org/licenses/>.
 
 # Written by David MacKenzie, with help from
-# Franc,ois Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
+# François Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
 # Roland McGrath, Noah Friedman, david d zuhn, and many others.
 
 
diff --git a/lib/autoconf/autoupdate.m4 b/lib/autoconf/autoupdate.m4
index adef7fb4..068e9b7f 100644
--- a/lib/autoconf/autoupdate.m4
+++ b/lib/autoconf/autoupdate.m4
@@ -25,7 +25,7 @@
 # respectively.  If not, see <https://www.gnu.org/licenses/>.
 
 # Written by David MacKenzie, with help from
-# Franc,ois Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
+# François Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
 # Roland McGrath, Noah Friedman, david d zuhn, and many others.
 
 
diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index a388599c..96a784a4 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -24,7 +24,7 @@
 
 # Written by David MacKenzie, with help from
 # Akim Demaille, Paul Eggert,
-# Franc,ois Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
+# François Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
 # Roland McGrath, Noah Friedman, david d zuhn, and many others.
 
 
diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4
index d8e4e6b1..22e2ae5f 100644
--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -24,7 +24,7 @@
 # respectively.  If not, see <https://www.gnu.org/licenses/>.
 
 # Written by David MacKenzie, with help from
-# Franc,ois Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
+# François Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
 # Roland McGrath, Noah Friedman, david d zuhn, and many others.
 
 
diff --git a/lib/autoconf/functions.m4 b/lib/autoconf/functions.m4
index de01f74a..110e2f05 100644
--- a/lib/autoconf/functions.m4
+++ b/lib/autoconf/functions.m4
@@ -23,7 +23,7 @@
 # respectively.  If not, see <https://www.gnu.org/licenses/>.
 
 # Written by David MacKenzie, with help from
-# Franc,ois Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
+# François Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
 # Roland McGrath, Noah Friedman, david d zuhn, and many others.
 
 
@@ -560,7 +560,7 @@ AC_DEFUN([_AC_FUNC_FNMATCH_IF],
   [# Some versions of Solaris, SCO, and the GNU C Library
# have a broken or incompatible fnmatch.
    # So we run a test program.  If we are cross-compiling, take no chance.
-   # Thanks to John Oleynick, Franc,ois Pinard, and Paul Eggert for this test.
+   # Thanks to John Oleynick, François Pinard, and Paul Eggert for this test.
AC_RUN_IFELSE(
   [AC_LANG_PROGRAM(
 [#include 
diff --git a/lib/autoconf/general.m4 b/lib/autoconf/general.m4
index 5540ae05..29243142 100644
--- a/lib/autoconf/general.m4
+++ b/lib/autoconf/general.m4
@@ -26,7 +26,7 @@ Inc.
 # respectively.  If not, see <https://www.gnu.org/licenses/>.
 
 # Written by David MacKenzie, with help from
-# Franc,ois Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
+# François Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
 # Roland McGrath, Noah Friedman, david d zuhn, and many others.
 
 
diff --git a/lib/autoconf/headers.m4 b/lib/autoconf/headers.m4
index 5fde7f5a..c5acd16e 100644
--- a/lib/autoconf/headers.m4
+++ b/lib/autoconf/headers.m4
@@ -25,7 +25,7 @@
 # respectively.  If not, see <https://www.gnu.org/licenses/>.
 
 # Written by David MacKenzie, with help from
-# Franc,ois Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
+# François Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
 # Roland McGrath, Noah Friedman, david d zuhn, and many others.
 
 
diff --git a/lib/autoconf/lang.m4 b/lib/autoconf/lang.m4
index cbe39ad2..48da66b7 100644
--- a/lib/autoconf/lang.m4
+++ b/lib/autoconf/lang.m4
@@ -24,7 +24,7 @@
 # respectively.  If not, see <https://www.gnu.org/licenses/>.
 
 # Written by David MacKenzie, with help from
-# Franc,ois Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
+# François Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
 # Roland McGrath, Noah Friedman, david d zuhn, and many others.
 
 
diff --git a/lib/autoconf/libs.m4 b/lib/autoconf/libs.m4
index a9350c37..796eaeaa 100644
--- a/lib/autoconf/libs.m4
+++ b/lib/autoconf/libs.m4
@@ -24,7 +24,7 @@
 # respectively.  If not, see <https://www.gnu.org/licenses/>.
 
 # Written by David MacKenzie, with help from
-# Franc,ois Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
+# François Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor,
 # Roland McGrath, Noah Friedman, david d zuhn, and

[committed 3/3] Document C23

2022-12-24 Thread Paul Eggert
---
 doc/autoconf.texi | 32 +---
 1 file changed, 9 insertions(+), 23 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 7d56758a..d2d8c23d 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -21937,38 +21937,24 @@ wraparound on overflow, instead of rewriting the 
code.  The rest of this
 section attempts to give practical advice for this situation.
 
 To detect integer overflow portably when attempting operations like
-@code{sum = a + b}, you can use the @code{intprops} module of Gnulib.
-@xref{Gnulib}.  For example:
+@code{sum = a + b}, you can use the C23 @code{} macros
+@code{ckd_add}, @code{ckd_sub}, and @code{ckd_mul}.
+The following code adds two integers with overflow wrapping around
+reliably in the sum:
 
 @example
-#include 
-...
-/* Set sum = a + b, diagnosing overflow.  */
-if (!INT_ADD_OK (a, b, &sum))
-  return "integer overflow detected";
-/* Now the code can use 'sum'.  */
-@end example
-
-To add two integers with overflow wrapping around reliably in the sum,
-you can use @code{INT_ADD_WRAPV (a, b, &sum)} instead:
-
-@example
-#include 
+#include 
 ...
 /* Set sum = a + b, with wraparound.  */
-if (INT_ADD_WRAPV (a, b, &sum))
+if (ckd_add (&sum, a, b))
   /* 'sum' has just the low order bits.  */;
 else
   /* 'sum' is the correct answer.  */;
 @end example
 
-The @code{intprops} module supports similar macros for other arithmetic
-operations, e.g., @code{INT_SUBTRACT_OK} and @code{INT_MULTIPLY_WRAPV}.
-If your code is intended to run only on GCC 7 or later, you can instead
-use the GNU C primitives @code{__builtin_add_overflow},
-@code{__builtin_sub_overflow}, and @code{__builtin_mul_overflow}.
-The @code{intprops} module uses these GCC 7 primitives if available,
-so that the cost of invoking these macros is typically just one machine
+To be portable to pre-C23 platforms you can use Gnulib's
+@code{stdckdint} module, which emulates this part of C23 (@pxref{Gnulib}).
+Invoking the @code{stdckdint} macros typically costs just one machine
 instruction for the arithmetic and another instruction for the rare
 branch on overflow.
 
-- 
2.38.1




[committed 1/3] AC_USE_SYSTEM_EXTENSIONS now enables C23 Annex F

2022-12-24 Thread Paul Eggert
* lib/autoconf/specific.m4 (AC_USE_SYSTEM_EXTENSIONS):
Also define __STDC_WANT_IEC_60559_EXT__, for C23.
---
 NEWS | 3 +++
 doc/autoconf.texi| 5 -
 lib/autoconf/specific.m4 | 7 ++-
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index 7223fed6..33e1948c 100644
--- a/NEWS
+++ b/NEWS
@@ -21,6 +21,9 @@ GNU Autoconf NEWS - User visible changes.
   that you will get a confusing error message if you run autoconf on
   a configure.ac that neglects to use AC_INIT or AC_OUTPUT.
 
+*** AC_USE_SYSTEM_EXTENSIONS now enables C23 Annex F extensions
+  by defining __STDC_WANT_IEC_60559_EXT__.
+
 *** AC_SYS_LARGEFILE now arranges for 64-bit time_t if possible.
 
 *** m4sh diversions like BINSH have been renumbered.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 7ae8ca64..5948902f 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8926,12 +8926,15 @@ Enable extensions specified by ISO/IEC TS 18661-1:2014.
 @item __STDC_WANT_IEC_60559_DFP_EXT__
 @cvindex __STDC_WANT_IEC_60559_DFP_EXT__
 Enable extensions specified by ISO/IEC TS 18661-2:2015.
+@item __STDC_WANT_IEC_60559_EXT__
+@cvindex __STDC_WANT_IEC_60559_EXT__
+Enable extensions specified by C23 Annex F.
 @item __STDC_WANT_IEC_60559_FUNCS_EXT__
 @cvindex __STDC_WANT_IEC_60559_FUNCS_EXT__
 Enable extensions specified by ISO/IEC TS 18661-4:2015.
 @item __STDC_WANT_IEC_60559_TYPES_EXT__
 @cvindex __STDC_WANT_IEC_60559_TYPES_EXT__
-Enable extensions specified by ISO/IEC TS 18661-3:2015.
+Enable extensions specified by C23 Annex H and by ISO/IEC TS 18661-3:2015.
 @item __STDC_WANT_LIB_EXT2__
 @cvindex __STDC_WANT_LIB_EXT2__
 Enable extensions specified by ISO/IEC TR 24731-2:2010.
diff --git a/lib/autoconf/specific.m4 b/lib/autoconf/specific.m4
index 0a9adba5..576212a3 100644
--- a/lib/autoconf/specific.m4
+++ b/lib/autoconf/specific.m4
@@ -545,11 +545,15 @@ AH_VERBATIM([USE_SYSTEM_EXTENSIONS],
 #ifndef __STDC_WANT_IEC_60559_DFP_EXT__
 # undef __STDC_WANT_IEC_60559_DFP_EXT__
 #endif
+/* Enable extensions specified by C23 Annex F.  */
+#ifndef __STDC_WANT_IEC_60559_EXT__
+# undef __STDC_WANT_IEC_60559_EXT__
+#endif
 /* Enable extensions specified by ISO/IEC TS 18661-4:2015.  */
 #ifndef __STDC_WANT_IEC_60559_FUNCS_EXT__
 # undef __STDC_WANT_IEC_60559_FUNCS_EXT__
 #endif
-/* Enable extensions specified by ISO/IEC TS 18661-3:2015.  */
+/* Enable extensions specified by C23 Annex H and ISO/IEC TS 18661-3:2015.  */
 #ifndef __STDC_WANT_IEC_60559_TYPES_EXT__
 # undef __STDC_WANT_IEC_60559_TYPES_EXT__
 #endif
@@ -619,6 +623,7 @@ dnl it should only be defined when necessary.
   AC_DEFINE([__STDC_WANT_IEC_60559_ATTRIBS_EXT__])
   AC_DEFINE([__STDC_WANT_IEC_60559_BFP_EXT__])
   AC_DEFINE([__STDC_WANT_IEC_60559_DFP_EXT__])
+  AC_DEFINE([__STDC_WANT_IEC_60559_EXT__])
   AC_DEFINE([__STDC_WANT_IEC_60559_FUNCS_EXT__])
   AC_DEFINE([__STDC_WANT_IEC_60559_TYPES_EXT__])
   AC_DEFINE([__STDC_WANT_LIB_EXT2__])
-- 
2.38.1




Re: [Update install instruction for macOS] Update install instruction for macOS

2022-11-20 Thread Paul Eggert

On 2022-11-20 08:19, Minsoo Choo wrote:

I tried many methods to solve this, and when I installed perl from source, the 
problem was solved.


Sure, but this sounds like a routine Perl installation problem, one that 
can occur on many platforms. It's not clear why Autoconf needs to go 
into details about how its prerequisites can be messed up, or why macOS 
needs a special shout-out.




Re: [Update install instruction for macOS] Update install instruction for macOS

2022-11-19 Thread Paul Eggert

On 2022-11-19 13:20, Minsoo Choo wrote:

+On macOS, users should not use the default perl, but manually install
+it fromhttps://www.perl.org/get.html.


Could you explain why this advice is helpful? What is the default perl 
version on macOS, and do different macOS versions have different perl 
versions, and why doesn't the most recent macOS version work with Autoconf?




Re: [PATCH] bootstrap: reject m4 versions only older than 1.4.8

2022-10-05 Thread Paul Eggert
Thanks for mentioning the problem. I think the code is right here and 
the documentation is wrong, so I installed the attached instead. The 
idea is that people building from Git should have reasonably up-to-date 
tools, and it's not too much to ask them to have m4 1.4.16 (2011) or later.From 85c0db3433edf053a477976aa1e2e4deb84d5905 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Wed, 5 Oct 2022 18:06:20 -0700
Subject: [PATCH] Update M4 version numbers in documentation

---
 README| 4 ++--
 README-hacking| 2 +-
 doc/autoconf.texi | 7 ---
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/README b/README
index f6bafdbb..f467f410 100644
--- a/README
+++ b/README
@@ -11,8 +11,8 @@ operating system features that the package can use, in the form of M4
 macro calls.
 
 Producing configuration scripts using Autoconf requires GNU M4 and
-Perl.  You should install GNU M4 (version 1.4.6 or later is required;
-1.4.14 or later is recommended) and Perl (5.006 or later) before
+Perl.  You should install GNU M4 (version 1.4.8 or later is required;
+1.4.16 or later is recommended) and Perl (5.006 or later) before
 configuring Autoconf, so that Autoconf's configure script can find
 them.  The configuration scripts produced by Autoconf are
 self-contained, so their users do not need to have Autoconf (or GNU
diff --git a/README-hacking b/README-hacking
index b4189ee4..e15128fa 100644
--- a/README-hacking
+++ b/README-hacking
@@ -16,7 +16,7 @@ tools we depend upon, including:
 
 - Automake 1.11+ <https://www.gnu.org/software/automake/>
 - Help2man 1.29+ <https://www.gnu.org/software/help2man/>
-- M4 1.4.6+ <https://www.gnu.org/software/m4/>
+- M4 1.4.16+ <https://www.gnu.org/software/m4/>
 - Perl 5.006+ <https://www.cpan.org/>
 - Texinfo 4.11+ <https://www.gnu.org/software/texinfo/>
 
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 38e08597..c6eebe2c 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -767,10 +767,10 @@ for more information.
 Autoconf imposes some restrictions on the names of macros used with
 @code{#if} in C programs (@pxref{Preprocessor Symbol Index}).
 
-Autoconf requires GNU M4 version 1.4.6 or later in order to
+Autoconf requires GNU M4 version 1.4.8 or later in order to
 generate the scripts.  It uses features that some versions of M4,
 including GNU M4 1.3, do not have.  Autoconf works better
-with GNU M4 version 1.4.14 or later, though this is not
+with GNU M4 version 1.4.16 or later, though this is not
 required.
 
 @xref{Autoconf 1}, for information about upgrading from version 1.
@@ -26428,7 +26428,8 @@ __file__
 __line__
 @end example
 
-Autoconf requires version 1.4.6 or later of GNU M4.
+Autoconf requires version 1.4.8 or later of GNU M4.
+It works better with version 1.4.16 or later.
 
 Since only software maintainers need to use Autoconf, and since GNU
 M4 is simple to configure and install, it seems reasonable to require
-- 
2.37.3



Re: [PATCH v2] specify void prototype for functions with no parameters

2022-09-18 Thread Paul Eggert

On 9/18/22 19:56, Sam James wrote:

In order to help with the rather mass breakage with newer Clang, could the 
autoconf
maintainers consider a small new release with this fix?


I doubt whether we have the time to do anything other than the usual, 
which is generate a new release at ab appropriate time. If you need 
something more urgent you can patch Autoconf for your distro (or better 
yet, patch Clang :-).




Re: [RESEND PATCH] autoconf: store autom4te request keys in sorted order

2022-09-09 Thread Paul Eggert

Thanks, I installed that.



Re: [PATCH] autoconf: fix build on upcoming GNU make-4.4

2022-09-09 Thread Paul Eggert
Thanks for the bug report. I installed the attached, which isn't the 
same as what you suggested, but which should fix the problem.From 31f673434ee402258b45e958c88acc8725d82b1a Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Fri, 9 Sep 2022 16:54:11 -0500
Subject: [PATCH] Port to GNU make 4.4

* cfg.mk (PATH): Assign eagerly, and simplify shell use, avoiding
use of the shell entirely if PWD is set, as it should be.
Problem reported by Sergei Trofimovich in:
https://lists.gnu.org/r/autoconf-patches/2022-09/msg7.html
---
 cfg.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cfg.mk b/cfg.mk
index 7e515130..82e896ed 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -18,7 +18,7 @@
 # This file is '-include'd into GNUmakefile.
 
 # Build with our own versions of these tools, when possible.
-export PATH = $(shell echo "`pwd`/tests:$$PATH")
+export PATH := $(or $(PWD),$(shell pwd))/tests:$(PATH)
 
 # Remove the autoreconf-provided INSTALL, so that we regenerate it.
 _autoreconf = autoreconf -i -v && rm -f INSTALL
-- 
2.37.2



Re: [PATCH v2] specify void prototype for functions with no parameters

2022-09-02 Thread Paul Eggert

On 9/2/22 10:42, Zack Weinberg wrote:

Why the #undef malloc here?


It's just a cut-and-paste typo. Thanks for reporting that. I installed 
the patch after correcting the typo.





Re: [PATCH v2] specify void prototype for functions with no parameters

2022-09-01 Thread Paul Eggert

On 9/1/22 11:53, Khem Raj wrote:


I ran into few problems. Some of them were latent issues[1] but some 
are problems[2] especially  using AC_CHECK_FUNCS when default compiler 
is C++ compiler not C compiler 



Thanks for checking. How about the attached patch instead? It's closer 
to what you originally suggested.


Zack, any thoughts on this sort of thing?
From 7a3bbca81b803ba116b83c82de378e840cc35f81 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 1 Sep 2022 16:19:50 -0500
Subject: [PATCH] Port to compilers that moan about K&R func decls
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lib/autoconf/c.m4 (AC_LANG_CALL, AC_LANG_FUNC_LINK_TRY):
Use '(void)' rather than '()' in function prototypes, as the latter
provokes fatal errors in some compilers nowadays.
* lib/autoconf/functions.m4 (AC_FUNC_STRTOD):
* tests/fortran.at (AC_F77_DUMMY_MAIN usage):
* tests/semantics.at (AC_CHECK_DECLS):
Don’t use () in a function decl.
---
 doc/autoconf.texi | 7 +++
 lib/autoconf/c.m4 | 6 +++---
 lib/autoconf/functions.m4 | 3 ---
 tests/fortran.at  | 8 
 tests/semantics.at| 2 +-
 5 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 67f31064..aa534ab7 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -5460,9 +5460,8 @@ the @samp{#undef malloc}):
 #include 
 #undef malloc
 
-#include 
-
-void *malloc ();
+#include 
+#undef malloc
 
 /* Allocate an N-byte block of memory from the heap.
If N is zero, allocate a 1-byte block.  */
@@ -8297,7 +8296,7 @@ needed:
 #  ifdef __cplusplus
  extern "C"
 #  endif
-   int F77_DUMMY_MAIN () @{ return 1; @}
+   int F77_DUMMY_MAIN (void) @{ return 1; @}
 #endif
 @end example
 
diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index abbb83fe..4751c7f5 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -133,7 +133,7 @@ m4_if([$2], [main], ,
 #ifdef __cplusplus
 extern "C"
 #endif
-char $2 ();])], [return $2 ();])])
+char $2 (void);])], [return $2 ();])])
 
 
 # AC_LANG_FUNC_LINK_TRY(C)(FUNCTION)
@@ -157,7 +157,7 @@ m4_define([AC_LANG_FUNC_LINK_TRY(C)],
 #define $1 innocuous_$1
 
 /* System header to define __stub macros and hopefully few prototypes,
-   which can conflict with char $1 (); below.  */
+   which can conflict with char $1 (void); below.  */
 
 #include 
 #undef $1
@@ -168,7 +168,7 @@ m4_define([AC_LANG_FUNC_LINK_TRY(C)],
 #ifdef __cplusplus
 extern "C"
 #endif
-char $1 ();
+char $1 (void);
 /* The GNU C library defines this for functions which it implements
 to always fail with ENOSYS.  Some functions are actually named
 something starting with __ and the normal name is an alias.  */
diff --git a/lib/autoconf/functions.m4 b/lib/autoconf/functions.m4
index 9f44a1ce..ee519a38 100644
--- a/lib/autoconf/functions.m4
+++ b/lib/autoconf/functions.m4
@@ -1613,9 +1613,6 @@ AC_DEFUN([AC_FUNC_STRTOD],
 AC_CACHE_CHECK(for working strtod, ac_cv_func_strtod,
 [AC_RUN_IFELSE([AC_LANG_SOURCE([[
 ]AC_INCLUDES_DEFAULT[
-#ifndef strtod
-double strtod ();
-#endif
 int
 main (void)
 {
diff --git a/tests/fortran.at b/tests/fortran.at
index 75b50b1a..473b39f6 100644
--- a/tests/fortran.at
+++ b/tests/fortran.at
@@ -233,7 +233,7 @@ void FOOBAR_F77 (double *x, double *y);
 #  ifdef __cplusplus
  extern "C"
 #  endif
-   int F77_DUMMY_MAIN () { return 1; }
+   int F77_DUMMY_MAIN (void) { return 1; }
 #endif
 
 int main(int argc, char *argv[])
@@ -315,7 +315,7 @@ void FOOBAR_FC(double *x, double *y);
 #  ifdef __cplusplus
  extern "C"
 #  endif
-   int FC_DUMMY_MAIN () { return 1; }
+   int FC_DUMMY_MAIN (void) { return 1; }
 #endif
 
 int main (int argc, char *argv[])
@@ -561,7 +561,7 @@ void @foobar@ (int *x);
 #  ifdef __cplusplus
  extern "C"
 #  endif
-   int F77_DUMMY_MAIN () { return 1; }
+   int F77_DUMMY_MAIN (void) { return 1; }
 #endif
 
 int main(int argc, char *argv[])
@@ -637,7 +637,7 @@ void @foobar@ (int *x);
 #  ifdef __cplusplus
  extern "C"
 #  endif
-   int FC_DUMMY_MAIN () { return 1; }
+   int FC_DUMMY_MAIN (void) { return 1; }
 #endif
 
 int main(int argc, char *argv[])
diff --git a/tests/semantics.at b/tests/semantics.at
index d24c4551..276d9744 100644
--- a/tests/semantics.at
+++ b/tests/semantics.at
@@ -207,7 +207,7 @@ AT_CHECK_MACRO([AC_CHECK_DECLS],
 		 [[extern int yes;
 		   enum { myenum };
 		   extern struct mystruct_s { int x[20]; } mystruct;
-		   extern int myfunc();
+		   extern int myfunc (int);
 		   #define mymacro1(arg) arg
 		   #define mymacro2]])
   # Ensure we can detect missing declarations of functions whose
-- 
2.37.2



Re: [PATCH v2] specify void prototype for functions with no parameters

2022-08-30 Thread Paul Eggert

On 8/29/22 21:35, Khem Raj wrote:

Compilers defaulting to C99 flag such functions as warning which fails
to compile when using -Werror


As mentioned earlier, projects should not use -Werror when configuring, 
for several reasons (this is just one). After you mentioned rsync was 
using something like -Werror I sent in a patch to the rsync folks, and 
rsync has been fixed:


https://github.com/WayneD/rsync/commit/9a3449a3980421f84ac55498ba565bc112b20d6c

What other projects are doing it? They should be fixed too, regardless 
of whether we change Autoconf here.


As for Autoconf, if we're going to make this change at all, we should do 
it fully. Something like the attached patch, perhaps. I haven't 
installed it.
From 5b81543769d4f59f6113bbad004465c6fb30e1f7 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Tue, 30 Aug 2022 16:34:14 -0500
Subject: [PATCH] Port to compilers that moan about K&R func decls
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lib/autoconf/c.m4 (AC_LANG_CALL, AC_LANG_FUNC_LINK_TRY):
Use '(int)' rather than '()' in function prototypes, as the latter
provokes fatal errors in some compilers nowadays.
* lib/autoconf/functions.m4 (AC_FUNC_STRTOD):
* tests/semantics.at (AC_CHECK_DECLS):
Don’t use () in a function decl.
---
 doc/autoconf.texi |  5 ++---
 lib/autoconf/c.m4 | 19 +--
 lib/autoconf/functions.m4 |  3 ---
 tests/semantics.at|  2 +-
 4 files changed, 8 insertions(+), 21 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 67f31064..4f4ec741 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -5460,9 +5460,8 @@ the @samp{#undef malloc}):
 #include 
 #undef malloc
 
-#include 
-
-void *malloc ();
+#include 
+#undef malloc
 
 /* Allocate an N-byte block of memory from the heap.
If N is zero, allocate a 1-byte block.  */
diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index abbb83fe..ca166557 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -126,14 +126,8 @@ m4_define([AC_LANG_CALL(C)],
 m4_if([$2], [main], ,
 [/* Override any GCC internal prototype to avoid an error.
Use char because int might match the return type of a GCC
-   builtin and then its argument prototype would still apply.
-   The 'extern "C"' is for builds by C++ compilers;
-   although this is not generally supported in C code, supporting it here
-   has little cost and some practical benefit (sr 110532).  */
-#ifdef __cplusplus
-extern "C"
-#endif
-char $2 ();])], [return $2 ();])])
+   builtin and then its argument prototype would still apply.  */
+char $2 (int);])], [return $2 (0);])])
 
 
 # AC_LANG_FUNC_LINK_TRY(C)(FUNCTION)
@@ -157,7 +151,7 @@ m4_define([AC_LANG_FUNC_LINK_TRY(C)],
 #define $1 innocuous_$1
 
 /* System header to define __stub macros and hopefully few prototypes,
-   which can conflict with char $1 (); below.  */
+   which can conflict with char $1 (int); below.  */
 
 #include 
 #undef $1
@@ -165,17 +159,14 @@ m4_define([AC_LANG_FUNC_LINK_TRY(C)],
 /* Override any GCC internal prototype to avoid an error.
Use char because int might match the return type of a GCC
builtin and then its argument prototype would still apply.  */
-#ifdef __cplusplus
-extern "C"
-#endif
-char $1 ();
+char $1 (int);
 /* The GNU C library defines this for functions which it implements
 to always fail with ENOSYS.  Some functions are actually named
 something starting with __ and the normal name is an alias.  */
 #if defined __stub_$1 || defined __stub___$1
 choke me
 #endif
-], [return $1 ();])])
+], [return $1 (0);])])
 
 
 # AC_LANG_BOOL_COMPILE_TRY(C)(PROLOGUE, EXPRESSION)
diff --git a/lib/autoconf/functions.m4 b/lib/autoconf/functions.m4
index 9f44a1ce..ee519a38 100644
--- a/lib/autoconf/functions.m4
+++ b/lib/autoconf/functions.m4
@@ -1613,9 +1613,6 @@ AC_DEFUN([AC_FUNC_STRTOD],
 AC_CACHE_CHECK(for working strtod, ac_cv_func_strtod,
 [AC_RUN_IFELSE([AC_LANG_SOURCE([[
 ]AC_INCLUDES_DEFAULT[
-#ifndef strtod
-double strtod ();
-#endif
 int
 main (void)
 {
diff --git a/tests/semantics.at b/tests/semantics.at
index d24c4551..276d9744 100644
--- a/tests/semantics.at
+++ b/tests/semantics.at
@@ -207,7 +207,7 @@ AT_CHECK_MACRO([AC_CHECK_DECLS],
 		 [[extern int yes;
 		   enum { myenum };
 		   extern struct mystruct_s { int x[20]; } mystruct;
-		   extern int myfunc();
+		   extern int myfunc (int);
 		   #define mymacro1(arg) arg
 		   #define mymacro2]])
   # Ensure we can detect missing declarations of functions whose
-- 
2.37.2



Re: [PATCH 2/2] AC_SYS_LARGEFILE now widens time_t if possible

2022-08-18 Thread Paul Eggert

On 8/18/22 12:29, Zack Weinberg wrote:
 it might be nice if the manual explained why AC_SYS_LARGEFILE should 
do this, instead of having it be solely AC_SYS_YEAR2038's responsibility. 



I gave that a shot by installing the following patch.

https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=bc66c26f488975ea9ad22033b9fa28809f4bf65e




Re: Problems building rsync with Clang 15 beta

2022-08-18 Thread Paul Eggert

On 8/18/22 09:38, Khem Raj wrote:

I think the autoconf patch should be good on its own merits regardless


It partly depends on how much we care about compatibility. Putting the 
'void' in there will break pre-C89 compilers, as well as C++ compilers 
pretending (badly) to be C compilers. I doubt whether we care about the 
former any more, but the latter might be an issue.




there were few other package
builds which started to succeed after this change in autoconf


Which ones, exactly, and why?



Problems building rsync with Clang 15 beta

2022-08-18 Thread Paul Eggert

On 8/17/22 23:58, Khem Raj wrote:

rsync which add -pedantic-errors option to cflags during configure


OK, that's the problem then. 'configure' should not use flags like 
-pedantic-errors. This has long been a property of 'autoconf'-generated 
scripts.


The simplest way to fix this would be for rsync to not add 
-pedantic-errors, as it's more trouble than it's worth. If rsync must 
add -pedantic-errors for some reason, it should do so at the very end of 
'configure', as in the attached untested patch, so as not to screw up 
earlier 'configure' tests; and perhaps it'd be better for rsync to also 
add -pedantic-errors only for GCC not Clang (since Clang is more likely 
to mutate further in this area).


Really, though, omitting -pedantic-errors entirely is the way to go. 
-pedantic-errors should be enabled only for special purposes, by 
explicit request of the person running 'configure' and/or 'make'; it's 
not suitable as a default option.


Anyway, please give this rsync patch a try. I'll cc it to the rsync 
mailing list to give rsync developers a heads-up about the compatibility 
problem building rsync with Clang 15 (which luckily does not exist yet :-).From e64a58387db46239902b610871a0eb81626e99ff Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 18 Aug 2022 07:46:28 -0700
Subject: [PATCH] Turn on -pedantic-errors at the end of 'configure'

Problem reported by Khem Raj in:
https://lists.gnu.org/r/autoconf-patches/2022-08/msg9.html
---
 configure.ac | 35 ---
 1 file changed, 20 insertions(+), 15 deletions(-)

diff --git a/configure.ac b/configure.ac
index d185b2d3..7e9514f7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1071,21 +1071,6 @@ elif test x"$ac_cv_header_popt_h" != x"yes"; then
 with_included_popt=yes
 fi
 
-if test x"$GCC" = x"yes"; then
-if test x"$with_included_popt" != x"yes"; then
-	# Turn pedantic warnings into errors to ensure an array-init overflow is an error.
-	CFLAGS="$CFLAGS -pedantic-errors"
-else
-	# Our internal popt code cannot be compiled with pedantic warnings as errors, so try to
-	# turn off pedantic warnings (which will not lose the error for array-init overflow).
-	# Older gcc versions don't understand -Wno-pedantic, so check if --help=warnings lists
-	# -Wpedantic and use that as a flag.
-	case `$CC --help=warnings 2>/dev/null | grep Wpedantic` in
-	*-Wpedantic*) CFLAGS="$CFLAGS -pedantic-errors -Wno-pedantic" ;;
-	esac
-fi
-fi
-
 AC_MSG_CHECKING([whether to use included libpopt])
 if test x"$with_included_popt" = x"yes"; then
 AC_MSG_RESULT($srcdir/popt)
@@ -1444,6 +1429,26 @@ case "$CC" in
 ;;
 esac
 
+# Enable -pedantic-errors last, so that it doesn't mess up other
+# 'configure' tests.  For example, Autoconf uses empty function
+# prototypes like 'int main () {}' which Clang 15's -pedantic-errors
+# would reject.  Generally it's not a good idea to try to run
+# 'configure' itself with strict compiler checking.
+if test x"$GCC" = x"yes"; then
+if test x"$with_included_popt" != x"yes"; then
+	# Turn pedantic warnings into errors to ensure an array-init overflow is an error.
+	CFLAGS="$CFLAGS -pedantic-errors"
+else
+	# Our internal popt code cannot be compiled with pedantic warnings as errors, so try to
+	# turn off pedantic warnings (which will not lose the error for array-init overflow).
+	# Older gcc versions don't understand -Wno-pedantic, so check if --help=warnings lists
+	# -Wpedantic and use that as a flag.
+	case `$CC --help=warnings 2>/dev/null | grep Wpedantic` in
+	*-Wpedantic*) CFLAGS="$CFLAGS -pedantic-errors -Wno-pedantic" ;;
+	esac
+fi
+fi
+
 AC_CONFIG_FILES([Makefile lib/dummy zlib/dummy popt/dummy shconfig])
 AC_OUTPUT
 
-- 
2.37.1



Re: [PATCH] specify void prototype for functions with no parameters

2022-08-17 Thread Paul Eggert

On 8/17/22 16:25, Khem Raj wrote:

right and I am not passing -Werror to configure but its newer version
of clang ( clang 15) which is turning these warnings into errors
by default now.


Wait, so clang 15 by default refuses to compile this C program?

void f() {}




Re: [PATCH] specify void prototype for functions with no parameters

2022-08-17 Thread Paul Eggert

On 8/17/22 09:51, Khem Raj wrote:

Compilers defaulting to C99 flag such functions as warning which fails
to compile when using -Werror


Sure, but one should never run 'configure' with -Werror.



[PATCH] Port AC_CHECK_HEADER_STDBOOL to C23

2022-08-13 Thread Paul Eggert
Modernize the bool documentation a bit too.
* lib/autoconf/headers.m4 (AC_CHECK_HEADER_STDBOOL):
Allow C23 too.
---
 NEWS| 19 +---
 doc/autoconf.texi   | 21 ++---
 lib/autoconf/headers.m4 | 69 -
 3 files changed, 37 insertions(+), 72 deletions(-)

diff --git a/NEWS b/NEWS
index 204f95f1..1e6a978b 100644
--- a/NEWS
+++ b/NEWS
@@ -45,18 +45,13 @@ GNU Autoconf NEWS - User visible changes.
   represent cache file timestamps, thus avoiding some problems where
   automake incorrectly decides not to regenerate stale caches.
 
-*** AC_HEADER_STDBOOL and AC_CHECK_HEADER_STDBOOL are less picky.
-
-  When compiling C++, a ‘stdbool.h’ that exists, but does nothing, is
-  acceptable no matter what version of the C++ standard is in use.
-
-  (ISO C++ 2011 says that ‘stdbool.h’ should exist for compatibility
-  with C, but should *not* define ‘bool’, ‘true’, or ‘false’ as
-  macros.  ISO C++ 1998 doesn’t mention ‘stdbool.h’ at all.  Some C++
-  compilers implement the 2011 rule in their C++98 mode as well.
-  ‘bool’, ‘true’, and ‘false’ have been built into the C++ language
-  since the beginning, so a ‘stdbool.h’ that exists but does nothing
-  should be fine for all reasonable C++ programs.)
+*** AC_HEADER_STDBOOL, AC_CHECK_HEADER_STDBOOL are obsolescent and less picky.
+
+  These macros are now obsolescent, as programs can simply include
+  stdbool.h unconditionally.  If you use these macros, they now accept
+  a stdbool.h that exists but does nothing, so long as ‘bool’, ‘true’,
+  and ‘false’ work anyway.  This is for compatibility with C 2023 and
+  with C++.
 
 * Noteworthy changes in release 2.71 (2021-01-28) [stable]
 
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 209840c2..06a16333 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -6141,6 +6141,9 @@ Check whether @file{stdbool.h} exists and conforms to C99 
or later,
 and cache the result in the @code{ac_cv_header_stdbool_h} variable.
 If the type @code{_Bool} is defined, define @code{HAVE__BOOL} to 1.
 
+This macro is obsolescent, as all current C compilers have @file{stdbool.h},
+a header that is itself obsolescent as of C 2023.
+
 This macro is intended for use by Gnulib (@pxref{Gnulib}) and other
 packages that supply a substitute @file{stdbool.h} on platforms lacking
 a conforming one.  The @code{AC_HEADER_STDBOOL} macro is better for code
@@ -6303,8 +6306,18 @@ New programs need not use this macro.
 @caindex header_stdbool_h
 If @file{stdbool.h} exists and conforms to C99 or later, define
 @code{HAVE_STDBOOL_H} to 1; if the type @code{_Bool} is defined, define
-@code{HAVE__BOOL} to 1.  To fulfill the standard's requirements, your
-program could contain the following code:
+@code{HAVE__BOOL} to 1.
+
+This macro is obsolescent, as all current C compilers have
+@file{stdbool.h}, a header that is itself obsolescent as of C 2023.
+Nowadays programs that need @code{bool}, @code{true} and @code{false}
+can include @file{stdbool.h} unconditionally, without using
+@code{AC_HEADER_STDBOOL}, and if such a program needs to be portable
+only to C 2023 or later it need not even include @file{stdbool.h}.
+
+This macro was originally intended for programs that needed to be
+portable to C89.  These obsolete programs could use the following code,
+so long as they assigned only 0 or 1 to @code{bool} variables:
 
 @example
 @group
@@ -6326,8 +6339,8 @@ typedef bool _Bool;
 @end group
 @end example
 
-Alternatively you can use the @samp{stdbool} package of Gnulib
-(@pxref{Gnulib}).  It simplifies your code so that it can say just
+Alternatively if you still need portability to C89 you can use the
+@samp{stdbool} package of Gnulib (@pxref{Gnulib}).  It lets code say just
 @code{#include }, and it adds support for less-common
 platforms.
 
diff --git a/lib/autoconf/headers.m4 b/lib/autoconf/headers.m4
index 5cd1f4d5..caf36fa4 100644
--- a/lib/autoconf/headers.m4
+++ b/lib/autoconf/headers.m4
@@ -572,27 +572,27 @@ fi
 
 # AC_CHECK_HEADER_STDBOOL
 # -
-# Check for stdbool.h that conforms to C99.
+# Check for stdbool.h that conforms to C99 or later.
 AN_IDENTIFIER([bool], [AC_CHECK_HEADER_STDBOOL])
 AN_IDENTIFIER([true], [AC_CHECK_HEADER_STDBOOL])
 AN_IDENTIFIER([false],[AC_CHECK_HEADER_STDBOOL])
 AC_DEFUN([AC_CHECK_HEADER_STDBOOL],
   [AC_CHECK_TYPES([_Bool])
-   AC_CACHE_CHECK([for stdbool.h that conforms to C99],
+   AC_CACHE_CHECK([for stdbool.h that conforms to C99 or later],
  [ac_cv_header_stdbool_h],
  [AC_COMPILE_IFELSE(
 [AC_LANG_PROGRAM(
[[#include 
 
- #ifndef __bool_true_false_are_defined
-   #error "__bool_true_false_are_defined is not defined"
- #endif
- char a[__bool_true_false_are_defined == 1 ? 1 : -1];
+ /* "true" and "false" should be usable in #if expressions and
+integer constant expressions, and "bool" should be a valid
+type na

[PATCH 2/2] AC_SYS_LARGEFILE now widens time_t if possible

2022-08-09 Thread Paul Eggert
This change is taken from Gnulib, and is needed for apps like GDB.
* lib/autoconf/specific.m4 (_AC_SYS_YEAR2038_TEST_INCLUDES)
(_AC_SYS_YEAR2038, AC_SYS_YEAR2038): New macros, taken (with
renaming) from Gnulib.
(_AC_SYS_LARGEFILE_MACRO_VALUE): #undef before #define.
(AC_SYS_LARGEFILE): Prefer AS_IF and AS_CASE to doing it by hand.
Widen time_t if possible, too.  Define  __MINGW_USE_VC2005_COMPAT
early if needed.
---
 NEWS |   6 ++
 doc/autoconf.texi|  33 +-
 lib/autoconf/specific.m4 | 134 +++
 3 files changed, 159 insertions(+), 14 deletions(-)

diff --git a/NEWS b/NEWS
index ef0f5f83..204f95f1 100644
--- a/NEWS
+++ b/NEWS
@@ -21,7 +21,13 @@ GNU Autoconf NEWS - User visible changes.
   that you will get a confusing error message if you run autoconf on
   a configure.ac that neglects to use AC_INIT or AC_OUTPUT.
 
+*** AC_SYS_LARGEFILE now arranges for 64-bit time_t if possible.
+
+
 ** New features
+
+*** New macro AC_YEAR2038 for 64-bit time_t.
+
 ** Obsolete features and new warnings
 
 *** Autoconf now quotes 'like this' instead of `like this'.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index fa5a9f48..209840c2 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8869,6 +8869,7 @@ if the system supports @samp{#!}, @samp{no} if not.
 @acindex{SYS_LARGEFILE}
 @cvindex _FILE_OFFSET_BITS
 @cvindex _LARGE_FILES
+@cvindex _TIME_BITS
 @ovindex CC
 @cindex Large file support
 @cindex LFS
@@ -8877,13 +8878,15 @@ Arrange for 64-bit file offsets, known as
 large-file support}.  On some hosts, one must use special compiler
 options to build programs that can access large files.  Append any such
 options to the output variable @code{CC}.  Define
-@code{_FILE_OFFSET_BITS} and @code{_LARGE_FILES} if necessary.
+@code{_FILE_OFFSET_BITS}, @code{_LARGE_FILES}, and @code{_TIME_BITS}
+if necessary.
 
 Large-file support can be disabled by configuring with the
 @option{--disable-largefile} option.
 
-If you use this macro, check that your program works even when
-@code{off_t} is wider than @code{long int}, since this is common when
+If you use this macro, check that your program works even when the types
+@code{blkcnt_t}, @code{dev_t}, @code{ino_t}, @code{off_t}, and @code{time_t}
+are wider than @code{long int}, since this is common when
 large-file support is enabled.  For example, it is not correct to print
 an arbitrary @code{off_t} value @code{X} with @code{printf ("%ld",
 (long int) X)}.  Also, when using this macro in concert with
@@ -8915,6 +8918,30 @@ system.  If so, set the shell variable 
@code{ac_cv_sys_posix_termios} to
 @samp{yes}.  If not, set the variable to @samp{no}.
 @end defmac
 
+@defmac AC_SYS_YEAR2038
+@acindex{SYS_YEAR2038}
+@cvindex _TIME_BITS
+@ovindex CC
+@cindex Year 2038
+If the default @code{time_t} type is a signed 32-bit integer that stops
+working in the year 2038, then arrange to use a wider @code{time_t} if
+possible and report a fatal error otherwise.  Define @code{_TIME_BITS}
+if necessary.
+
+Wider-time support can be disabled by configuring with the
+@option{--disable-year2038} option.
+
+Regardless of whether you use this macro, portable programs should not
+assume that @code{time_t} fits into @code{long int}.  For example, it is
+not correct to print an arbitrary @code{time_t} value @code{X} with
+@code{printf ("%ld", (long int) X)}.  Also, when using this macro in
+concert with @code{AC_CONFIG_HEADERS}, be sure that @file{config.h} is
+included before any system header.
+
+Although @code{AC_SYS_LARGFILE} also widens @code{time_t} if possible,
+it merely warns if this cannot be done, rather than reporting a fatal error.
+@end defmac
+
 @node C and Posix Variants
 @section C and Posix Variants
 
diff --git a/lib/autoconf/specific.m4 b/lib/autoconf/specific.m4
index 757d678b..0af41176 100644
--- a/lib/autoconf/specific.m4
+++ b/lib/autoconf/specific.m4
@@ -85,6 +85,112 @@ AU_DEFUN([AC_ARG_ARRAY], [],
 with arguments. Remove this warning when you adjust your code.])
 
 
+# _AC_SYS_YEAR2038_TEST_INCLUDES
+# --
+AC_DEFUN([_AC_SYS_YEAR2038_TEST_INCLUDES],
+[[
+  #include 
+  /* Check that time_t can represent 2**32 - 1 correctly.  */
+  #define LARGE_TIME_T \\
+((time_t) (((time_t) 1 << 30) - 1 + 3 * ((time_t) 1 << 30)))
+  int verify_time_t_range[(LARGE_TIME_T / 65537 == 65535
+   && LARGE_TIME_T % 65537 == 0)
+  ? 1 : -1];
+]])
+
+# _AC_SYS_YEAR2038(REQUIRE-YEAR2038-SAFE)
+# ---
+AC_DEFUN([_AC_SYS_YEAR2038],
+[
+ AC_ARG_ENABLE([year2038],
+   [  --disable-year2038  omit support for timestamps past the year 2038])
+ AS_IF([test "$enable_year2038" != no],
+ [
+  dnl On many systems, time_t is already a 64-bit type.
+  dnl On those systems where time_t is still 32-bit, it requires kernel
+  dnl and libc support to make it 64-bit. For glibc 2.34 and later on Linux,
+  dnl defining _TIME_BI

[PATCH 1/2] Fix compilation errors in 32-bit C++ mode on HP-UX 11/ia64

2022-08-09 Thread Paul Eggert
This should render unnecessary Gnulib’s gl_SET_LARGEFILE_SOURCE hack
https://lists.gnu.org/r/bug-gnulib/2019-12/msg00046.html
* lib/autoconf/functions.m4 (AC_FUNC_FSEEKO):
On that platform, simply set _LARGEFILE_SOURCE.
---
 lib/autoconf/functions.m4 | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/lib/autoconf/functions.m4 b/lib/autoconf/functions.m4
index 70eb8760..9f44a1ce 100644
--- a/lib/autoconf/functions.m4
+++ b/lib/autoconf/functions.m4
@@ -649,7 +649,13 @@ AC_DEFUN([AC_FUNC_FSEEKO],
 [_AC_SYS_LARGEFILE_MACRO_VALUE(_LARGEFILE_SOURCE, 1,
[ac_cv_sys_largefile_source],
[Define to 1 to make fseeko visible on some hosts (e.g. glibc 2.2).],
-   [[#include  /* for off_t */
+   [[#if defined __hpux && !defined _LARGEFILE_SOURCE
+  #include 
+  #if LONG_MAX >> 31 == 0
+   #error "32-bit HP-UX 11/ia64 needs _LARGEFILE_SOURCE for fseeko in C++"
+  #endif
+ #endif
+ #include  /* for off_t */
  #include ]],
[[int (*fp) (FILE *, off_t, int) = fseeko;
  return fseeko (stdin, 0, 0) && fp (stdin, 0, 0);]])
-- 
2.37.1




Re: [PATCH] handle LIBS="" in test case 567

2022-07-14 Thread Paul Eggert

On 6/29/22 16:34, Jeff Shimoda [Marbles504] wrote:


The fix back in 2005 was to add code to
tests/local.at to replace the single quotes in LIBS='' so the
comparison passes.  I would like to propose a similar fix which
replaces double quotes.


Thanks, I installed that. This doesn't solve the problem in general but 
I hope it's good enough for reasonable shells.




Re: [PATCH] add rm conftest.o in lib/autoconf/lang.m4

2022-06-29 Thread Paul Eggert

On 6/29/22 16:22, Jeff Shimoda [Marbles504] wrote:

Just following up with this.  Any thoughts?  If you'd like I can open
up a bug in Savanna for this.


Should be no need, as I committed something along those lines here:

https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=76beb33bfe435a4434fd63920affe38620166d85

Sorry, I forgot to send you email about that.




Re: [PATCH] add rm conftest.o in lib/autoconf/lang.m4

2022-06-21 Thread Paul Eggert

On 6/21/22 16:24, Marbles504 wrote:

+rm -f conftest.$ac_ext conftest$ac_cv_exeext conftest.out conftest.o


Don't you also need to remove conftest.obj? Or is it conftest.$ac_objext 
and require _AC_COMPILER_OBJEXT? Or the latter may be a bridge too far.





Re: [PATCH] build-aux/config.guess: Add current Haiku targets arm,arm64,riscv64

2022-05-23 Thread Paul Eggert
Please send config.guess patches to , the email 
address in the config.guess file. Autoconf is downstream from config. 
Thanks.




Re: Fix memoryleak in conftest.c

2022-03-31 Thread Paul Eggert

On 3/31/22 02:31, Raphael Isemann wrote:

the obvious memory leak here is causing problems
with a downstream compiler (the compiler is more strict about memory
leaks and keeps generating warnings when used in autoconf projects
that compile this file during configure)


Usually there's a way to suppress these false alarms, e.g., by 
configuring with the appropriate CFLAGS. It's not a bad idea to do that 
with mature code, as the leak diagnostics are typically more trouble 
than they're worth. The GNU Coding standards say,


"Memory analysis tools such as valgrind can be useful, but don’t 
complicate a program merely to avoid their false alarms. For example, if 
memory is used until just before a process exits, don’t free it simply 
to silence such a tool." 
<https://www.gnu.org/prep/standards/html_node/Memory-Usage.html>



All that being said, I installed the attached to try to help out, 
sometime in the distant future when everyone has upgraded to some future 
version of Autoconf.From 374b0e9942bb87dd8d0c956d7c03c85dcc489bf7 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 31 Mar 2022 23:25:35 -0700
Subject: [PATCH] Work around memory-leak false alarms

Problem reported by Raphael Isemann in:
https://lists.gnu.org/r/autoconf-patches/2022-03/msg7.html
* lib/autoconf/c.m4 (_AC_C_C99_TEST_MAIN, AC_C_FLEXIBLE_ARRAY_MEMBER):
* tests/data/gnulib_std_gnu11_2020_08_17.m4 (_AC_C_C99_TEST_HEADER):
Free storage allocated via malloc, to pacify overly-picky
implementations that issue false alarms about memory leaks.
---
 lib/autoconf/c.m4 | 6 +-
 tests/data/gnulib_std_gnu11_2020_08_17.m4 | 2 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index 48bd49a3..42fbcbd0 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -1330,6 +1330,8 @@ ac_c_conftest_c99_main='
   ia->datasize = 10;
   for (int i = 0; i < ia->datasize; ++i)
 ia->data[i] = i * 1.234;
+  // Work around memory leak warnings.
+  free (ia);
 
   // Check named initializers.
   struct named_init ni = {
@@ -2170,7 +2172,9 @@ AC_DEFUN([AC_C_FLEXIBLE_ARRAY_MEMBER],
 	struct s *p = (struct s *) malloc (offsetof (struct s, d)
 	   + m * sizeof (double));
 	p->d[0] = 0.0;
-	return p->d != (double *) NULL;]])],
+	m = p->d != (double *) NULL;
+	free (p);
+	return m;]])],
[ac_cv_c_flexmember=yes],
[ac_cv_c_flexmember=no])])
   if test $ac_cv_c_flexmember = yes; then
diff --git a/tests/data/gnulib_std_gnu11_2020_08_17.m4 b/tests/data/gnulib_std_gnu11_2020_08_17.m4
index da52cd6f..21f7cc7a 100644
--- a/tests/data/gnulib_std_gnu11_2020_08_17.m4
+++ b/tests/data/gnulib_std_gnu11_2020_08_17.m4
@@ -319,6 +319,8 @@ AC_DEFUN([_AC_C_C99_TEST_BODY],
   ia->datasize = 10;
   for (int i = 0; i < ia->datasize; ++i)
 ia->data[i] = i * 1.234;
+  // Work around memory leak warnings.
+  free (ia);
 
   // Check named initializers.
   struct named_init ni = {
-- 
2.32.0



Re: doc: Stop deadnaming Sarah Manthey

2022-03-12 Thread Paul Eggert

On 3/12/22 12:18, Sarah Manthey wrote:

There was a fourth instance, in ChangeLog.3, I believe.


Yes, but that one's historical so the historical name and email address 
was kept there.




Re: doc: Stop deadnaming Sarah Manthey

2022-03-12 Thread Paul Eggert

OK, I installed the attached; if there are mistakes please let us know.From 00358457d09c19ff6b5ec7ed98708540d1994a5f Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 12 Mar 2022 11:32:35 -0800
Subject: [PATCH] doc: update Manthey name+email

---
 AUTHORS| 2 +-
 THANKS | 2 +-
 lib/autoconf/status.m4 | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/AUTHORS b/AUTHORS
index b6a63f21..1308bbae 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -78,7 +78,7 @@ Peter O'Gorman  pe...@pogma.com 2004-11-14
 Toshio Ernie Kuratomi   tos...@tiki-lounge.com  2004-11-17
 Roger Leigh rle...@whinlatter.ukfsn.org 2004-12-09
 Ian Lance Taylori...@airs.com2004-12-22
-Daniel Manthey  dan_mant...@partech.com 2005-02-14
+Sarah Manthey   man...@gmail.com2005-02-14
 Gregorio Guidi  gre...@gentoo.org   2005-03-03
 Bruno Haiblebr...@clisp.org 2005-06-12
 Toby Oliver Hilary Whiteto...@cam.ac.uk 2005-10-18
diff --git a/THANKS b/THANKS
index ec89a9f7..7b0aba29 100644
--- a/THANKS
+++ b/THANKS
@@ -93,7 +93,6 @@ Corinna Vinschencorinna-cyg...@cygwin.com
 Cort Dougan c...@cs.nmt.edu
 D'Arcy A MacIsaac   ?
 Dalibor Topic   robi...@kaffe.org
-Dan Manthey dan_mant...@partech.com
 Daniel Carroll  d...@mesastate.edu
 Daniel Elstner  daniel.ki...@gmail.com
 Daniel Jacobowitz   d...@mvista.com
@@ -383,6 +382,7 @@ Sam Steingold   s...@gnu.org
 Sam Varshavchik mr...@courier-mta.com
 Sander Niemeijerniemei...@science-and-technology.nl
 santilínlis...@gestiong.org
+Sarah Manthey   man...@gmail.com
 Scott Bambrough sco...@corelcomputer.com
 Scott McCreary  scott...@gmail.com
 Scott Stanton   stan...@scriptics.com
diff --git a/lib/autoconf/status.m4 b/lib/autoconf/status.m4
index c2721a85..92e1c30e 100644
--- a/lib/autoconf/status.m4
+++ b/lib/autoconf/status.m4
@@ -318,7 +318,7 @@ m4_define([_AC_AWK_LITERAL_LIMIT],
 # The intention is to have readable config.status and configure, even
 # though this m4 code might be scary.
 #
-# This code was written by Dan Manthey and rewritten by Ralf Wildenhues.
+# This code was written by Sarah Manthey and rewritten by Ralf Wildenhues.
 #
 # This macro is expanded inside a here document.  If the here document is
 # closed, it has to be reopened with
-- 
2.32.0



Re: doc: Stop deadnaming Sarah Manthey

2022-03-12 Thread Paul Eggert
Thanks, could you please write copyright-cl...@fsf.org and update them 
as to your current name and email address? We have to be a bit careful 
about these sorts of things for the usual copyright-law reasons.


Also, could you please let me know when your name and/or email address 
changed? Our change logs use names and email addresses as of when the 
change was made.




Re: [PATCH] doc: clarify integer requirements in some functions

2022-02-12 Thread Paul Eggert

On 2/12/22 01:03, Mike Frysinger wrote:

i
don't think, based on the description of AS_VAR_ARITH, this is unreasonable:
   blah=2
   AS_VAR_ARITH([foo], [$blah + 0.1])


True enough. I installed the attached, which is a bit fancier than what 
you proposed, and which nails down more details about AS_VAR_ARITH.From cbec82b65f6fb8f0092c908abaa05bd9aa300571 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 12 Feb 2022 14:47:52 -0800
Subject: [PATCH] Clarify documentation of number format

Problem reported by Mike Frysinger in:
https://lists.gnu.org/r/autoconf-patches/2022-02/msg7.html
---
 doc/autoconf.texi   | 36 +---
 lib/m4sugar/m4sh.m4 | 16 ++--
 2 files changed, 31 insertions(+), 21 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 49ee61cd..f5caa71d 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -12974,8 +12974,7 @@ m4_apply([m4_join], [[|], [1], [2]])
 
 @defmac m4_count (@var{arg}, @dots{})
 @msindex{count}
-This macro returns the decimal count of the number of arguments it was
-passed.
+This macro returns the number of arguments it was passed.
 @end defmac
 
 @defmac m4_curry (@var{macro}, @var{arg}@dots{})
@@ -13474,8 +13473,19 @@ respectively.
 @subsection Arithmetic computation in M4
 
 The following macros facilitate integer arithmetic operations.
+
 Where a parameter is documented as taking an arithmetic expression, you
 can use anything that can be parsed by @code{m4_eval}.
+Any other numeric parameter should consist of an optional sign followed
+by one or more decimal digits; it is treated as a decimal integer.
+
+Macros that expand to a number do so as either @samp{0}, or an optional
+@samp{-} followed by a nonzero decimal digit followed by zero or more
+decimal digits.
+
+Due to @command{m4} limitations, arithmetic expressions and numeric
+parameters should use only numbers that fit into a 32-bit signed
+integer.
 
 @defmac m4_cmp (@var{expr-1}, @var{expr-2})
 @msindex{cmp}
@@ -13512,13 +13522,13 @@ m4_list_cmp([1],  [1, 2])
 
 @defmac m4_max (@var{arg}, @dots{})
 @msindex{max}
-This macro was introduced in Autoconf 2.62.  Expand to the decimal value
+This macro was introduced in Autoconf 2.62.  Expand to the value
 of the maximum arithmetic expression among all the arguments.
 @end defmac
 
 @defmac m4_min (@var{arg}, @dots{})
 @msindex{min}
-This macro was introduced in Autoconf 2.62.  Expand to the decimal value
+This macro was introduced in Autoconf 2.62.  Expand to the value
 of the minimum arithmetic expression among all the arguments.
 @end defmac
 
@@ -14329,11 +14339,15 @@ assigning the result as the contents of the polymorphic shell variable
 @var{var}.  The code takes advantage of shells that provide @samp{$(())}
 for fewer forks, but uses @command{expr} as a fallback.  Therefore, the
 syntax for a valid @var{expression} is rather limited: all operators
-must occur as separate shell arguments and with proper quoting, there is
-no portable equality operator, all variables containing numeric values
-must be expanded prior to the computation, all numeric values must be
-provided in decimal without leading zeroes, and the first shell argument
-should not be a negative number.  In the following example, this snippet
+must occur as separate shell arguments and with proper quoting;
+the only operators supported are @samp{*}, @samp{/}, @samp{%}, binary
+@samp{+}, binary @samp{-}, @samp{>}, @samp{>=}, @samp{<}, @samp{<=},
+@samp{!=}, @samp{&}, and @samp{|};
+all variables containing numbers must be expanded prior to the computation;
+the first shell argument must not start with @samp{-};
+and each number must be an optional @samp{-} followed by one or more
+decimal digits, where the first digit is nonzero if there is more than
+one digit.  In the following example, this snippet
 will print @samp{(2+3)*4 == 20}.
 
 @example
@@ -16942,7 +16956,7 @@ When it is available, using arithmetic expansion provides a noticeable
 speedup in script execution; but testing for support requires
 @command{eval} to avoid syntax errors.  The following construct is used
 by @code{AS_VAR_ARITH} to provide arithmetic computation when all
-arguments are provided in decimal and without a leading zero, and all
+arguments are decimal integers without leading zeros, and all
 operators are properly quoted and appear as distinct arguments:
 
 @example
@@ -19821,7 +19835,7 @@ XSI options are those in @option{-bcdox}.  The BSD
 @command{hexdump} program can be used instead.
 
 In some versions of some operating systems derived from Solaris 11,
-@command{od} prints decimal byte values padded with zeroes rather than
+@command{od} prints decimal byte values padded with zeros rather than
 with spaces:
 
 @smallexample
diff --git a/lib/m4sugar/m4sh.m4 b/lib/m4sugar/m4sh.m4
index e0d50431..6909012e 100644
--- a/lib/m4sugar/m4sh.m4
+++ b/lib/m4sugar/m4sh.m4
@@ -1498,8 +1498,8 @@ fi])
 # AS_FUNCTION_DESCRIBE(NAME

Re: [PATCH] doc: clarify integer requirements in some functions

2022-02-12 Thread Paul Eggert

On 2/12/22 00:28, Mike Frysinger wrote:

These functions do not accept decimal values with fractional parts.
Describe them in terms of integers to clarify.


I dunno, those values all must be integers by their nature so saying 
"integer" in the doc doesn't help much; conversely, if the doc omits the 
word "decimal" people might think the numbers could be octal or hex.


Although we could uniformly replace "decimal" with "nonnegative decimal 
integer without excess leading zeros" that would be overkill. Perhaps we 
could just add a sentence somewhere saying "By 'integer' we mean 
'nonnegative decimal integer without excess leading zeros'" and leave 
the rest of the doc as-is.




Re: doc: Document how to deal with missing 'join'

2022-01-12 Thread Paul Eggert

Thanks, I installed that.



[INSTALLED] doc: update ‘find’ info

2021-10-09 Thread Paul Eggert
* doc/autoconf.texi (Limitations of Usual Tools):
Mention a few more GNU ‘find’ options that are not portable.
Modernize a bit.
---
 doc/autoconf.texi | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index db736c7f..17a6326e 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -19500,13 +19500,17 @@ Tru64/OSF 5.1 @command{fgrep} does not match an empty 
pattern.
 @item @command{find}
 @c -
 @prindex @command{find}
-The @option{-maxdepth} option seems to be GNU specific.
-Tru64 v5.1, NetBSD 1.5 and Solaris @command{find}
-commands do not understand it.
+Many operands of GNU @command{find} are not standardized by Posix and
+are missing on many platforms. These nonportable operands include
+@option{-follow}, @option{-maxdepth}, @option{-mindepth},
+@option{-printf}, and @option{,}.  See the
+@uref{https://@/pubs.opengroup.org/@/onlinepubs/@/9699919799/@/utilities/@/find.html,
+Posix spec for @command{find}} for @command{find} operands that
+should be portable nowadays.
 
 The replacement of @samp{@{@}} is guaranteed only if the argument is
 exactly @emph{@{@}}, not if it's only a part of an argument.  For
-instance on DU, and HP-UX 10.20 and HP-UX 11:
+instance, on HP-UX 11:
 
 @example
 $ @kbd{touch foo}
@@ -19516,6 +19520,7 @@ $ @kbd{find . -name foo -exec echo "@{@}-@{@}" \;}
 
 @noindent
 while GNU @command{find} reports @samp{./foo-./foo}.
+Posix allows either behavior.
 
 
 @anchor{grep}
-- 
2.30.2




Re: [PATCH] fortran.m4: Filter mingw intrinsic libraries

2021-09-01 Thread Paul Eggert

Thanks, I installed that with a smaller commit message.

The rest of Autoconf uses 'mingw*' instead of '*mingw*' so I removed the 
leading '*' in a followup patch; hope that's OK.


See attached.
>From 696684fff56e05c2af9f85e3f41401dbf1920f8c Mon Sep 17 00:00:00 2001
From: Keno Fischer 
Date: Wed, 1 Sep 2021 19:39:32 -0400
Subject: [PATCH 1/2] fortran.m4: Filter mingw intrinsic libraries

* lib/autoconf/fortran.m4 (_AC_FC_LIBRARY_LDFLAGS):
Filter out mingw libraries too.
Problem and fix reported by Keno Fischer in
https://lists.gnu.org/r/autoconf-patches/2021-09/msg0.html
Copyright-paperwork-exempt: Yes
---
 lib/autoconf/fortran.m4 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4
index d393c669..8d682152 100644
--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -665,10 +665,10 @@ while test $[@%:@] != 1; do
 	-lang* | -lcrt*.o | -lc | -lgcc* | -lSystem | -libmil | -little \
 	  |-LANG:=* | -LIST:* | -LNO:* | -link)
 	  ;;
-	-lkernel32)
+	-lkernel32 | -lmingw* | -lmoldname)
 	  # Ignore this library only on Windows-like systems.
 	  case $host_os in
-	  cygwin* | msys* ) ;;
+	  cygwin* | msys* | *mingw*) ;;
 	  *)
 	  _AC_LIST_MEMBER_IF($ac_arg, $ac_cv_[]_AC_LANG_ABBREV[]_libs, ,
 			 ac_cv_[]_AC_LANG_ABBREV[]_libs="$ac_cv_[]_AC_LANG_ABBREV[]_libs $ac_arg")
-- 
2.30.2

>From 32e53cd79384fc243300eb3d66dde83d8e8b13e2 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Wed, 1 Sep 2021 19:07:32 -0700
Subject: [PATCH 2/2] =?UTF-8?q?fortran:=20*mingw*=20=E2=86=92=20mingw*=20i?=
 =?UTF-8?q?n=20previous=20patch?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lib/autoconf/fortran.m4 (_AC_FC_LIBRARY_LDFLAGS): Omit a ‘*’.
---
 lib/autoconf/fortran.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4
index 8d682152..1d2bdda3 100644
--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -668,7 +668,7 @@ while test $[@%:@] != 1; do
 	-lkernel32 | -lmingw* | -lmoldname)
 	  # Ignore this library only on Windows-like systems.
 	  case $host_os in
-	  cygwin* | msys* | *mingw*) ;;
+	  cygwin* | msys* | mingw*) ;;
 	  *)
 	  _AC_LIST_MEMBER_IF($ac_arg, $ac_cv_[]_AC_LANG_ABBREV[]_libs, ,
 			 ac_cv_[]_AC_LANG_ABBREV[]_libs="$ac_cv_[]_AC_LANG_ABBREV[]_libs $ac_arg")
-- 
2.30.2



[PATCH] Modernize discussion of integer overflow

2021-08-31 Thread Paul Eggert
* doc/autoconf.texi (Integer Overflow, Integer Overflow Basics)
(Signed Overflow Examples, Optimization and Wraparound):
Modernize discussion to take current compiler and Gnulib
technology into account.
---
 doc/autoconf.texi | 173 +-
 1 file changed, 95 insertions(+), 78 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 590be1c4..34559414 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -21706,13 +21706,10 @@ the programs work well enough in practice.
 @cindex signed integer overflow
 @cindex wraparound arithmetic
 
-In practice many portable C programs assume that signed integer overflow wraps
-around reliably using two's complement arithmetic.  Yet the C standard
-says that program behavior is undefined on overflow, and in a few cases
-C programs do not work on some modern implementations because their
-overflows do not wrap around as their authors expected.  Conversely, in
-signed integer remainder, the C standard requires overflow
-behavior that is commonly not implemented.
+Although some traditional C programs assume that signed integer overflow
+wraps around reliably using two's complement arithmetic, the C standard
+says that program behavior is undefined on overflow, and these C
+programs many not work on many modern implementations.
 
 @menu
 * Integer Overflow Basics:: Why integer overflow is a problem
@@ -21729,7 +21726,8 @@ behavior that is commonly not implemented.
 @cindex signed integer overflow
 @cindex wraparound arithmetic
 
-In languages like C, unsigned integer overflow reliably wraps around;
+In languages like C, integer overflow wraps around for unsigned
+integer types that are at least as wide as @code{unsigned int};
 e.g., @code{UINT_MAX + 1} yields zero.
 This is guaranteed by the C standard and is
 portable in practice, unless you specify aggressive,
@@ -21740,15 +21738,18 @@ In contrast, the C standard says that signed integer 
overflow leads to
 undefined behavior where a program can do anything, including dumping
 core or overrunning a buffer.  The misbehavior can even precede the
 overflow.  Such an overflow can occur during addition, subtraction,
-multiplication, division, and left shift.
-
-Despite this requirement of the standard, many C programs and Autoconf
-tests assume that signed integer overflow silently wraps around modulo a
-power of two, using two's complement arithmetic, so long as you cast the
-resulting value to a signed integer type or store it into a signed
-integer variable.  If you use conservative optimization flags, such
-programs are generally portable to the vast majority of modern
-platforms, with a few exceptions discussed later.
+multiplication, division, and left shift.  It can even occur for
+unsigned types like @code{unsigned short int} that are narrower
+than @code{int}, as values of these types are widened to @code{int}
+before computation.
+
+Despite this requirement of the standard, some C programs assume that
+signed integer overflow silently wraps around modulo a power of two,
+using two's complement arithmetic, so long as you convert the resulting
+value to a signed integer type.  These programs can have problems,
+especially when optimization is enabled.  If you assume a GCC-like
+compiler, you can work around the problems by compiling with GCC's
+@code{-fwrapv} option; however, this is not portable.
 
 For historical reasons the C standard also allows implementations with
 ones' complement or signed magnitude arithmetic, but it is safe to
@@ -21756,9 +21757,9 @@ assume two's complement nowadays.
 
 Also, overflow can occur when converting an out-of-range value to a
 signed integer type.  Here a standard implementation must define what
-happens, but this might include raising an exception.  In practice all
-known implementations support silent wraparound in this case, so you need
-not worry about other possibilities.
+happens, and this can include raising an exception.  Although practical
+implementations typically wrap around silently in this case, a few
+debugging implementations trap instead.
 
 @node Signed Overflow Examples
 @subsection Examples of Code Assuming Wraparound Overflow
@@ -21767,14 +21768,15 @@ not worry about other possibilities.
 @cindex signed integer overflow
 @cindex wraparound arithmetic
 
-There has long been a tension between what the C standard requires for
-signed integer overflow, and what C programs commonly assume.  The
+There was long a tension between what the C standard requires for signed
+integer overflow, and what traditional C programs commonly assumed.  The
 standard allows aggressive optimizations based on assumptions that
-overflow never occurs, but many practical C programs rely on overflow
-wrapping around.  These programs do not conform to the standard, but
-they commonly work in practice because compiler writers are
-understandably reluctant to implement optimizations that would break
-many programs, unless perhaps a u

[PATCH] Port test to next m4 version

2021-08-31 Thread Paul Eggert
* tests/tools.at (autom4te cache):
Allow m4 to quote 'like this' as well as 'like this'.
---
 tests/tools.at | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/tests/tools.at b/tests/tools.at
index 77d9c1e6..48cdd924 100644
--- a/tests/tools.at
+++ b/tests/tools.at
@@ -98,10 +98,20 @@ AT_CHECK_M4SUGAR
 # We moved a file: it should fail
 mkdir sub
 mv foo sub
-AT_CHECK_M4SUGAR([], [1], [],
+case `$M4 no/such/file 2>&1` in
+  *\`no/such/file*)
+AT_CHECK_M4SUGAR([], [1], [],
 [m4:script.4s:1: cannot open `foo': No such file or directory
 autom4te: error: m4 failed with exit status: 1
 ])
+;;
+  *)
+AT_CHECK_M4SUGAR([], [1], [],
+[m4:script.4s:1: cannot open 'foo': No such file or directory
+autom4te: error: m4 failed with exit status: 1
+])
+;;
+esac
 
 # But if we change the main file, then we should no longer complain of
 # missing files.
-- 
2.31.1




Re: [PATCH v4] Fortran Cray pointer macro support

2021-08-16 Thread Paul Eggert
Thanks for doing all that work. I took a quick look at it, and although 
I'm no Fortran expert (my only Fortran experience consists of helping to 
write a Fortran compiler in the early 1970s!) I didn't see any problems. 
It shouldn't break any existing Autoconf uses, at any rate.


I committed it here:

https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=6cfdc564894709122e71700ee95a71a4cb992a60



[INSTALLED 1/2] Document unquoted here-documents better

2021-07-20 Thread Paul Eggert
Problem reported by Bruno Haible (sr #110518).
* doc/autoconf.texi (Generating Sources)
(Running the Preprocessor, Running the Compiler)
(Running the Linker, Runtime): Briefly mention that the program
snippets are expanded as unquoted here-documents.
(Here-Documents): Document escaping needed in unquoted
here-documents.  Remove mention of \" glitch in OpenBSD 2.7 sh;
that old system has not been supported for many years.
Remove advice that every \ must be quoted, as that sort
of quoting (though harmless) is not needed and is rarely done.
* lib/autoconf/c.m4 (AC_C_BIGENDIAN, _AC_LANG_OPENMP(Fortran 77)):
* lib/autoconf/types.m4 (AC_TYPE_LONG_LONG_INT): Properly quote
code snippets.  The backslash-newline typos were harmless, and the
backslash-$ typo has unspecified behavior as per POSIX though the
typo is harmless on all shells I know of.  However, Autoconf
should follow its own quoting advice.
---
 doc/autoconf.texi | 70 +--
 lib/autoconf/c.m4 |  6 ++--
 lib/autoconf/types.m4 |  2 +-
 3 files changed, 38 insertions(+), 40 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 33cebc37..965d6502 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -9409,6 +9409,10 @@ Note that the @var{source} is evaluated exactly once, 
like regular
 Autoconf macro arguments, and therefore (i) you may pass a macro
 invocation, (ii) if not, be sure to double quote if needed.
 
+The @var{source} text is expanded as an unquoted here-document, so
+@samp{$}, @samp{`} and some @samp{\}s should be backslash-escaped.
+@xref{Here-Documents}.
+
 This macro issues a warning during @command{autoconf} processing if
 @var{source} does not include an expansion of the macro
 @code{AC_LANG_DEFINES_PROVIDED} (note that both @code{AC_LANG_SOURCE} and
@@ -9605,8 +9609,12 @@ Fortran, or Go, since those languages require no 
preprocessor.
 @acindex{PREPROC_IFELSE}
 Run the preprocessor of the current language (@pxref{Language Choice})
 on the @var{input}, run the shell commands @var{action-if-true} on
-success, @var{action-if-false} otherwise.  The @var{input} can be made
-by @code{AC_LANG_PROGRAM} and friends.
+success, @var{action-if-false} otherwise.
+
+The @var{input} can be made by @code{AC_LANG_PROGRAM} and friends.
+The @var{input} text is expanded as an unquoted here-document, so
+@samp{$}, @samp{`} and some @samp{\}s should be backslash-escaped.
+@xref{Here-Documents}.
 
 This macro uses @code{CPPFLAGS}, but not @code{CFLAGS}, because
 @option{-g}, @option{-O}, etc.@: are not valid options to many C
@@ -9672,8 +9680,8 @@ See below for some problems involving this macro.
 @defmac AC_EGREP_CPP (@var{pattern}, @var{program}, @
   @ovar{action-if-found}, @ovar{action-if-not-found})
 @acindex{EGREP_CPP}
-@var{program} is the text of a C or C++ program, on which shell
-variable, back quote, and backslash substitutions are performed.  If the
+@var{program} is the text of a C or C++ program, which is expanded as an
+unquoted here-document (@pxref{Here-Documents}).  If the
 output of running the preprocessor on @var{program} matches the
 extended regular expression @var{pattern}, execute shell commands
 @var{action-if-found}, otherwise execute @var{action-if-not-found}.
@@ -9722,8 +9730,12 @@ to compile a small program that uses that feature.
 @acindex{COMPILE_IFELSE}
 Run the compiler and compilation flags of the current language
 (@pxref{Language Choice}) on the @var{input}, run the shell commands
-@var{action-if-true} on success, @var{action-if-false} otherwise.  The
-@var{input} can be made by @code{AC_LANG_PROGRAM} and friends.
+@var{action-if-true} on success, @var{action-if-false} otherwise.
+
+The @var{input} can be made by @code{AC_LANG_PROGRAM} and friends.
+The @var{input} text is expanded as an unquoted here-document, so
+@samp{$}, @samp{`} and some @samp{\}s should be backslash-escaped.
+@xref{Here-Documents}.
 
 It is customary to report unexpected failures with
 @code{AC_MSG_FAILURE}.  This macro does not try to link; use
@@ -9773,10 +9785,14 @@ program.
 Run the compiler (and compilation flags) and the linker of the current
 language (@pxref{Language Choice}) on the @var{input}, run the shell
 commands @var{action-if-true} on success, @var{action-if-false}
-otherwise.  The @var{input} can be made by @code{AC_LANG_PROGRAM} and
-friends.  If needed, @var{action-if-true} can further access the
+otherwise.  If needed, @var{action-if-true} can further access the
 just-linked program file @file{conftest$EXEEXT}.
 
+The @var{input} can be made by @code{AC_LANG_PROGRAM} and friends.
+The @var{input} text is expanded as an unquoted here-document, so
+@samp{$}, @samp{`} and some @samp{\}s should be backslash-escaped.
+@xref{Here-Documents}.
+
 @code{LDFLAGS} and @code{LIBS} are used for linking, in addition to the
 current compilation flags.
 
@@ -9816,6 +9832,10 @@ status of 0 when executed, run shell commands 
@var{action-if-true}.
 Otherwise, run shell commands @var{a

Re: [PATCH 0/3] RFC: automated bootstrap script

2021-02-05 Thread Paul Eggert

On 2/5/21 7:34 AM, Zack Weinberg wrote:

it does
involve some relatively invasive changes to the actual code, notably
rewriting the ‘autoconf’ driver program in Perl so the bootstrap
script doesn’t have to know how to generate M4sh scripts


All worth it in my opinion. Thanks for doing that.



Re: AS_IF

2020-10-12 Thread Paul Eggert

On 10/6/20 5:52 PM, Zack Weinberg wrote:


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.


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).



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


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.
>From 3cdc910d229d33e5a98e66b64ee1506a0c2e262c Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sun, 11 Oct 2020 23:53:41 -0700
Subject: [PATCH] doc: improve AS_CASE, AS_IF doc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

See the thread containing:
https://lists.gnu.org/r/bug-gnulib/2020-10/msg00033.html
* doc/autoconf.texi: Distinguish between Solaris 10 and later.
(Balancing Parentheses): Mention the Posix syntax for ‘case’,
typically a better solution nowadays.
(AS_CASE, AS_IF): Mention AC_REQUIRE, portability, parens.
(Prerequisite Macros): Tighten up example and make it less dated.
Say that AS_CASE and AS_IF are not needed outside macros.
* NEWS: Don’t mention AS_FOR.  It’s not documented, and for
good reason since it is so ... quirky.
---
 NEWS  |   8 ++--
 doc/autoconf.texi | 115 +-
 2 files changed, 77 insertions(+), 46 deletions(-)

diff --git a/NEWS b/NEWS
index be82eab9..356a28b0 100644
--- a/NEWS
+++ b/NEWS
@@ -34,10 +34,10 @@ GNU Autoconf NEWS - User visible changes.
  variables used later in the configure script, or in generated
  Makefiles.
 
-   - Autoconf macros that use AC_REQUIRE internally, are not safe to
- use inside of hand-written shell control-flow constructs.  Use
- AS_IF, AS_CASE, AS_FOR, etc. instead.  (See the “Prerequisite
- Macros” section of the manual for further explanation.)
+   - Autoconf macros that use AC_REQUIRE are not safe to use in shell
+ control-flow constructs that appear outside of macros defined by
+ AC_DEFUN.  Use AS_IF, AS_CASE, etc. instead.  (See the
+ “Prerequisite Macros” section of the manual for details.)
 
  The set of macros that use AC_REQUIRE internally may change from
  release to release.  The only macros that are guaranteed *not* to
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 9f05cee8..9a52fbdb 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -11024,9 +11024,11 @@ Cambridge University computer lab at the time.
 @cindex parentheses, balancing
 @cindex unbalanced parentheses, managing
 
-One of the pitfalls of portable shell programming is that @command{case}
-statements require unbalanced parentheses (@pxref{case, , Limitations of
-Shell Builtins}).  With syntax highlighting
+One of the pitfalls of portable shell programming is that
+if you intend your script to run with obsolescent shells,
+@command{case} statements require unbalanced parentheses.
+@xref{case, , Limitations of Shell Builtins}.
+With syntax highlighting
 editors, the presence of unbalanced @samp{)} can interfere with editors
 that perform syntax highlighting of macro contents based on finding the
 matching @samp{(}.  Another concern is how much editing must be done
@@ -11066,6 +11068,19 @@ variations for defining @code{my_case} to be more robust, even when used
 without proper quoting, each with some benefits and some drawbacks.
 
 @itemize @w{}
+@item Use left parenthesis before pattern
+@example
+AC_DEFUN([my_case],
+[case $file_name in
+  (*.c) echo "C source code";;
+esac])
+@end example
+@noindent
+This is simple and provides balanced parentheses.  Although this is not
+portable to obsolescent shells (notably Solaris 10 @command{/bin/sh}),
+platforms with these shells invariably have a more-modern shell
+available somewhere so this approach typically suffices nowadays.
+
 @item Creative literal shell comment
 @example
 AC_DEFUN([my_case],
@@ -13758,8 +13773,15 @@ log files to separate distinct phases of script operation.
 Expand into a shell @samp{case} statement, where @var{word} is matched
 against one or more patterns.  @var{if-matched} is run if the
 corresponding pattern matched @var{word}, else @var{default} is run.
-Avoids several portability issues (@pxref{case, , Limitations of Shell
-Builtins}).
+@xref{Prerequisite Macros} for why
+this macro should be used instead of plain @samp{case} in code
+outside of an @code{AC_DEFUN} macro, when the contents of the
+@samp{case} use @code{AC_REQUIRE} directly or indirectly.
+@xref{case, , Limitations of Shell Builtins},
+for how this m

Re: [RFC PATCH 0/3] Work around autoconf/automake warnings skew (automake side)

2020-09-22 Thread Paul Eggert

On 9/22/20 3:47 PM, Karl Berry wrote:

Zack, the Automake changes look fine to me. Please commit/push at your
convenience, as far as I'm concerned. Thanks!!


They look good to me, too.



Re: [RFC PATCH 0/6] Work around autoconf/automake warnings skew

2020-09-22 Thread Paul Eggert

On 9/22/20 1:04 PM, Zack Weinberg wrote:


The main thing I want to discuss before merging these patches is the
location of the new Perl function merge_WARNINGS.  I put it in
ChannelDefs.pm because that is where all the other code relating to
WARNINGS is, but it’s only used in autoreconf, so there’s an argument
for putting it in autoreconf instead, if only so we can modify it in
the future without having to go through automake.


I mildly prefer the way you did it. Thanks for looking into this.



Re: RFC PATCH 1/2] AS_INIT: try to ensure fds 0, 1, 2 are open

2020-08-27 Thread Paul Eggert

On 8/27/20 3:20 PM, Zack Weinberg wrote:

On Thu, Aug 27, 2020 at 2:09 PM Paul Eggert  wrote:



+  if (exec 3>&0) 2>/dev/null; then :; else exec 0&1) 2>/dev/null; then :; else exec 1>/dev/null; fi
+  if (exec 3>&2); then :; else exec 2>/dev/null; fi


This is all _AS_ENSURE_STANDARD_FDS needs to do; none of the other stuff is
needed and I suggest omitting it as a maintenance time-sink.


I can definitely see how the rest of it could turn into a maintenance
time sink, but are you sure we don't need a workaround of any kind for
this construct succeeding even though the target fd is closed, in very
old shells?


Buggy old shells likely won't benefit from the other stuff anyway, as they'll be 
running in older environments where the other stuff likely doesn't work anyway. 
So the other stuff has little benefit to counterbalance the maintenance timesink.


Another way to put it is that this fault in Autoconf-generated scripts has been 
around for decades and nobody cared because nobody triggered the problem. So the 
only people at all likely to trigger the problem now are people building in 
problematic new stripped-down virtualized platforms the likes of which we didn't 
see in earlier decades. These new platforms will surely not be running ancient 
buggy shells, not only because those buggy shells likely won't work for several 
other reasons, but also because the people building this stuff this new way 
don't care about ancient buggy shells.



not that 'read' from 0 or 'write' to 1 or 2 must succeed (there's never any 
guarantee of that).


I'm not 100% convinced by this argument but I don't have a real
counterargument either and in any case it's more on-topic for the
glibc thread, not here.


True enough.

If it helps, Jim Meyering and I went through this whole discussion years ago in 
coreutils and came up with an approach along the lines that I mentioned. See the 
Gnulib module fdopen, which is used by some GNU programs (though not coreutils 
yet! I should fix that.) Its core implementation is here:


https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/stdopen.c



Re: RFC PATCH 1/2] AS_INIT: try to ensure fds 0, 1, 2 are open

2020-08-27 Thread Paul Eggert

+  if (exec 3>&0) 2>/dev/null; then :; else exec 0&1) 2>/dev/null; then :; else exec 1>/dev/null; fi
+  if (exec 3>&2); then :; else exec 2>/dev/null; fi


This is all _AS_ENSURE_STANDARD_FDS needs to do; none of the other stuff is 
needed and I suggest omitting it as a maintenance time-sink.


POSIX programs and utilities merely need file descriptors 0, 1, and 2 to be 
open; it doesn't matter whether they're open for read or for write. The point is 
that an ordinary 'open' syscall should never return FDs 0 thru 2; not that 
'read' from 0 or 'write' to 1 or 2 must succeed (there's never any guarantee of 
that).




Re: [PATCH] tests: New helper macro AT_CHECK_MAKE.

2020-08-20 Thread Paul Eggert

The basic idea looks good, though I didn't check the patch in detail. Thanks.



Re: [RFC PATCH 0/2] Additional AC_INIT/AC_OUTPUT-related diagnostics

2020-08-17 Thread Paul Eggert

On 8/17/20 10:38 AM, Zack Weinberg wrote:

That's fair.  Do you have any comments on the patches themselves or
shall I go ahead and merge them?


No comments, please go ahead.



Re: [RFC PATCH 0/2] Additional AC_INIT/AC_OUTPUT-related diagnostics

2020-08-15 Thread Paul Eggert

On 8/14/20 11:44 AM, Zack Weinberg wrote:

I found a kludge that works,
but I’d like to hear opinions on whether we should instead postpone
this patch till after 2.70 so we can coordinate with automake on the
addition of the missing autom4te feature.


I would rather not postpone, since the patch sounds correct as-is (albeit 
kludgey) and we can clean it up at our leisure after Automake is updated.


Waiting for Automake might mean a long wait



Re: [PATCH] AC_LANG_INT_SAVE: Modernize function declarators (C89 and above).

2020-08-07 Thread Paul Eggert

On 8/7/20 1:01 PM, Vincent Lefevre wrote:

The program

int main(void)
{
   return 0;
}

compiles fine with g++, even using "-std=c++17 -pedantic".


I expect the problem was with non-GNU C++ compilers, not with g++. However, I'm 
not the C++ guy so I'm the wrong person to ask about the details. You could 
write to Bruno Haible - I think he was the one preferring 'int main () ...'.




Re: [PATCH] AC_LANG_INT_SAVE: Modernize function declarators (C89 and above).

2020-08-06 Thread Paul Eggert

On 8/6/20 4:25 PM, Vincent Lefevre wrote:

IMHO, in the mean time, a "void" for the parameter list should be
used when it makes sense.


For what it's worth, I count 13 instances of 'int main (void) { ... }' in Gnulib 
code, and 136 instances of 'int main () { ... }'. As I recall, the latter is for 
C++ compatibility, which I guess is not an issue with MPFR.


It's not a big deal either way, but if it helps MPFR out I suppose it's a win. I 
installed the attached two patches. The first one fixes the problem you 
mentioned, along with a similar issue in the 'inline' detection. The second one 
fixes a related problem with 'int main (int argc)'.
>From d3f54e6d5ca216594a8550c1404762a5b8f2ecec Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 6 Aug 2020 17:37:42 -0700
Subject: [PATCH 1/2] Pacify -Werror in two places
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Although this cannot easily be done in general, there are a couple
of places where it’s easy.
* lib/autoconf/c.m4 (AC_LANG_INT_SAVE (C)):
Change ‘()’ to ‘(void)’ to pacify picky compilers.
Problem reported by Vincent Lefevre in:
https://lists.gnu.org/r/autoconf-patches/2020-08/msg0.html
(AC_C_INLINE): Likewise.
---
 lib/autoconf/c.m4 | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index 0027f98b..eaef13a9 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -194,8 +194,8 @@ return test_array @<:@0@:>@;
 # But we include them only after the EXPRESSION has been evaluated.
 m4_define([AC_LANG_INT_SAVE(C)],
 [AC_LANG_PROGRAM([$1
-static long int longval () { return $2; }
-static unsigned long int ulongval () { return $2; }
+static long int longval (void) { return $2; }
+static unsigned long int ulongval (void) { return $2; }
 @%:@include 
 @%:@include ],
 [
@@ -1747,8 +1747,8 @@ for ac_kw in inline __inline__ __inline; do
   AC_COMPILE_IFELSE([AC_LANG_SOURCE(
 [#ifndef __cplusplus
 typedef int foo_t;
-static $ac_kw foo_t static_foo () {return 0; }
-$ac_kw foo_t foo () {return 0; }
+static $ac_kw foo_t static_foo (void) {return 0; }
+$ac_kw foo_t foo (void) {return 0; }
 #endif
 ])],
 		[ac_cv_c_inline=$ac_kw])
-- 
2.17.1

>From 38219077b2d677607cb3d7de12c54085d578a99c Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 6 Aug 2020 17:40:49 -0700
Subject: [PATCH 2/2] =?UTF-8?q?Avoid=20one-argument=20=E2=80=98main?=
 =?UTF-8?q?=E2=80=99?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* tests/autotest.at (C unit tests, C unit tests (EXEEXT)):
Avoid ‘int main (int argc)’ as the C standard says this
is not portable.
---
 tests/autotest.at | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/autotest.at b/tests/autotest.at
index dbd86460..5519e9c7 100644
--- a/tests/autotest.at
+++ b/tests/autotest.at
@@ -1904,7 +1904,7 @@ AC_OUTPUT
 
 # Test file
 AT_DATA([testprog.c],
-[[int main(int argc) { return argc == 2 ? 0 : 1; }
+[[int main (int argc, char **argv) { return argc == 2 ? 0 : 1; }
 ]])
 
 # Testsuite
@@ -1956,7 +1956,7 @@ AC_OUTPUT
 
 # Test file
 AT_DATA([testprog.c],
-[[int main(int argc) { return argc == 2 ? 0 : 1; }
+[[int main (int argc, char **argv) { return argc == 2 ? 0 : 1; }
 ]])
 
 # Testsuite
-- 
2.17.1



Re: [PATCH] AC_LANG_INT_SAVE: Modernize function declarators (C89 and above).

2020-08-06 Thread Paul Eggert

On 8/5/20 7:28 PM, Vincent Lefevre wrote:

Then "configure" should provide a way to use -Werror


I added that to the Autoconf TODO list; see attached. Unfortunately it's not 
something that would be trivial to do. In the meantime, I suggest not passing 
-Werror to 'configure'. (Or for this particular example, you can wait until C2x 
is supported. :-)
>From ef399ebb88d65eb674c9e9748ad223997d1e1ce2 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 6 Aug 2020 12:28:24 -0700
Subject: [PATCH] * TODO: Add -Werror support.

---
 TODO | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/TODO b/TODO
index 37b2e946..62619219 100644
--- a/TODO
+++ b/TODO
@@ -83,6 +83,13 @@ Harlan:
 ** Languages
 Integrate other Fortrans etc.
 
+** Picky compilers, e.g., gcc -Werror
+Many Autoconf-generated tests do the wrong thing if someone configures
+with CC='gcc -Werror' or with similar options.  It would be nice if
+these tests worked better with picky compilers.  This will require
+significant reworking in some cases, e.g., AC_CHECK_FUNCS will need
+to know the headers declaring the functions.
+
 ** AC_CHECK_FUNCS and AC_TRY_LINK_FUNC
 I have still not understood what's the difference  between the two
 which requires to have two different sources: AC_LANG_CALL and
-- 
2.17.1



Re: [PATCH] AC_LANG_INT_SAVE: Modernize function declarators (C89 and above).

2020-08-05 Thread Paul Eggert

On 8/5/20 10:32 AM, Vincent Lefevre wrote:

With MPFR, it works after applying this patch.


I don't see it as working with MPFR. If you try to build MPFR 4.1.0 with 
"./configure CFLAGS='-g3 -O2 -Werror=old-style-definition'", then 'configure' 
makes some other wrong decisions on my platform (Fedora 31 x86-64). For example, 
'configure' doesn't "#define STDC_HEADERS 1" as it should, and it creates the 
wrong value for global_symbol_pipe and for global_symbol_to_cdecl in the 
'libtool' file.


Perhaps none of these mistakes happened to bite you in your tests, but the point 
is that it's always been a bad idea to use -Werror in 'configure', and saying 
that something doesn't work when one configures with -Werror is not a good 
motivation for making a change to Autoconf.




Re: [PATCH] AC_LANG_INT_SAVE: Modernize function declarators (C89 and above).

2020-08-05 Thread Paul Eggert

On 8/5/20 3:59 AM, Vincent Lefevre wrote:

This allows one to avoid a failure with AC_COMPUTE_INT when using
the -Werror=old-style-definition GCC option.


Why is this needed? Telling 'configure' to use -Werror has never worked, for 
lots of other reasons.




Re: doc updates for section "Particular Functions"

2020-07-31 Thread Paul Eggert

On 7/31/20 5:01 AM, Bruno Haible wrote:

Oops, I withdraw 0003. (I had misunderstood what AC_FUNC_MMAP does.)
Please use this one instead.


Thanks, I installed those three patches, followed by the attached minor patch to 
Gnulib-related wording.
>From e9bfc7c7582a6b69bf753f2bea5d4cb1f669759a Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Fri, 31 Jul 2020 14:09:31 -0700
Subject: [PATCH] * doc/autoconf.texi: Tweak wording.

---
 doc/autoconf.texi | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 2a279ef2..6ad4dca1 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -4655,10 +4655,10 @@ on some architectures.  This section tries to make an inventory of these
 portability issues.  By definition, this list always requires
 additions.  A much more complete list is maintained by the Gnulib
 project (@pxref{Gnulib}), covering @ref{Function Substitutes, ,
-Current Posix Functions, gnulib, GNU gnulib}, @ref{Legacy Function
-Substitutes, , Legacy Functions, gnulib, GNU gnulib}, and @ref{Glibc
-Function Substitutes, , Glibc Functions, gnulib, GNU gnulib}.  Please
-help us keep the gnulib list as complete as possible.
+Current Posix Functions, gnulib, Gnulib}, @ref{Legacy Function
+Substitutes, , Legacy Functions, gnulib, Gnulib}, and @ref{Glibc
+Function Substitutes, , Glibc Functions, gnulib, Gnulib}.  Please
+help us keep the Gnulib list as complete as possible.
 
 @table @asis
 @item @code{exit}
@@ -4700,7 +4700,7 @@ typically assume @code{double} arguments.  On such a system,
 @code{isinf} incorrectly returns true for a finite @code{long double}
 argument that is outside the range of @code{double}.
 
-The best workaround for these issues is to use gnulib modules
+The best workaround for these issues is to use Gnulib modules
 @code{isinf} and @code{isnan} (@pxref{Gnulib}).  But a lighter weight
 solution involves code like the following.
 
@@ -4983,7 +4983,7 @@ should accept @option{-1} for @code{uid} and @code{gid}), define
 @code{HAVE_CHOWN}.  The result of this macro is cached in the
 @code{ac_cv_func_chown_works} variable.
 
-If you actually want a workaround, that is, a @code{chown} function is
+If you want a workaround, that is, a @code{chown} function that is
 available and works, you can use the Gnulib module @code{chown}.
 @xref{Gnulib}.
 @end defmac
@@ -5121,7 +5121,7 @@ may occur when compiling with @code{AC_SYS_LARGEFILE} on
 largefile-sensitive systems where @code{off_t} does not default to a
 64bit entity.  All systems with @code{fseeko} also supply @code{ftello}.
 
-Gnulib contains a module @code{fseeko}, that invokes @code{AC_FUNC_FSEEKO}
+The Gnulib module @code{fseeko} invokes @code{AC_FUNC_FSEEKO}
 and also contains workarounds for other portability problems of
 @code{fseeko}.  @xref{Gnulib}.
 @end defmac
@@ -5139,7 +5139,7 @@ define @code{HAVE_GETGROUPS}.  Set @code{GETGROUPS_LIBS} to any libraries
 needed to get that function.  This macro runs @code{AC_TYPE_GETGROUPS}.
 
 This macro is obsolescent. New programs need not use this macro.  But
-they may want to use the Gnulib module @code{getgroups}, that provides
+they may want to use the Gnulib module @code{getgroups}, which provides
 workarounds to other portability problems of this function.
 @end defmac
 
@@ -5337,8 +5337,8 @@ type @code{mbstate_t} are properly declared.
 The result of this macro is cached in the @code{ac_cv_func_mbrtowc}
 variable.
 
-Gnulib contains a module @code{mbrtowc} that not only ensures that the
-function is declared, but also works around a number of other portability
+The Gnulib module @code{mbrtowc} not only ensures that the
+function is declared, but also works around other portability
 problems of this function.
 @end defmac
 
@@ -5540,9 +5540,9 @@ the buffer argument.
 The result of this macro is cached in the
 @code{ac_cv_func_strerror_r_char_p} variable.
 
-Gnulib contains a module @code{strerror_r} that not only ensures that the
-function has the return type specified by Posix, but also works around a
-dozen of other portability problems of this function.
+The Gnulib module @code{strerror_r} not only ensures that the function
+has the return type specified by Posix, but also works around other
+portability problems of this function.
 @end defmac
 
 @anchor{AC_FUNC_STRFTIME}
@@ -5587,8 +5587,8 @@ If the @code{strtold} function exists and conforms to C99 or later, define
 
 This macro caches its result in the @code{ac_cv_func_strtold} variable.
 
-Gnulib contains a module @code{strtold} that not only ensures that the
-function exists, but also works around a dozen of other portability
+The Gnulib module @code{strtold} not only ensures that the
+function exists, but also works around other portability
 problems of this function.
 @end defmac
 
@@ -5846,9 +5846,9 @@ This section documents some collected knowledge about common headers,
 and the problems they cause.  By definition, this list alw

Re: [PATCH] Revert 'Fix logic error in _AC_PROG_LEX_YYTEXT_DECL (#109320)'

2020-07-16 Thread Paul Eggert

On 7/16/20 6:36 PM, Zack Weinberg wrote:

Shouldn't this be LIBS="$ac_cv_lib_lex $ac_save_LIBS" now?


Indeed it should. Good catch, especially since this code is not likely to be 
executed by anybody. Also, there was an unnecessary assignment to ac_cv_lib_lex 
before the for-loop. I fixed both problems and installed.




Re: [PATCH] Revert 'Fix logic error in _AC_PROG_LEX_YYTEXT_DECL (#109320)'

2020-07-16 Thread Paul Eggert

On 7/16/20 11:40 AM, Zack Weinberg wrote:

I believe that what's in trunk now should work fine for
cross-compilation of programs that don't require yywrap


I thought so too, but after eyeballing the trunk a bit I noticed a shell 
portability bug in the recently-added AC_PROG_LEX code. I then found a couple 
more instances of the same bug elsewhere in Autoconf (in rarely-executed code, I 
think).


The problem is that constructs like ${ac_lib:-none needed} don't conform to 
POSIX, as POSIX requires that the stuff after the :- be a single shell word. 
(The next time I meet Steve Bourne I want to give him an earfull)


I installed a doc patch describing the portability pitfall into Savannah master:

https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=2ff883c27e55b0c0d4a448614c1dee0492c9a7da

and would like to also install the attached patch to fix the code bugs. I have 
held off installing this latter patch, though, as I don't want to get in the way 
of whatever testing you're doing.
>From 870c40f9df86dcf0d80a4ab6aca2aaa9dffae38e Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 16 Jul 2020 17:35:36 -0700
Subject: [PATCH] Fix ${VAR-NONWORD} bugs

* lib/autoconf/functions.m4 (AC_FUNC_SELECT_ARGTYPES):
* lib/autoconf/programs.m4 (AC_FUNC_SELECT_ARGTYPES):
* lib/autotest/general.m4 (AT_INIT):
Rewrite to avoid ${VAR-VALUE} where VALUE is not a shell word.
---
 lib/autoconf/functions.m4 |  5 ++---
 lib/autoconf/programs.m4  | 11 +++
 lib/autotest/general.m4   |  7 +--
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/lib/autoconf/functions.m4 b/lib/autoconf/functions.m4
index 645a7c60..718503f5 100644
--- a/lib/autoconf/functions.m4
+++ b/lib/autoconf/functions.m4
@@ -1526,7 +1526,8 @@ AC_DEFUN([AC_FUNC_SELECT_ARGTYPES],
 [AC_CHECK_HEADERS_ONCE([sys/select.h sys/socket.h])
 AC_CACHE_CHECK([types of arguments for select],
 [ac_cv_func_select_args],
-[for ac_arg234 in 'fd_set *' 'int *' 'void *'; do
+[ac_cv_func_select_args='int,int *,struct timeval *'
+for ac_arg234 in 'fd_set *' 'int *' 'void *'; do
  for ac_arg1 in 'int' 'size_t' 'unsigned long int' 'unsigned int'; do
   for ac_arg5 in 'struct timeval *' 'const struct timeval *'; do
AC_COMPILE_IFELSE(
@@ -1546,8 +1547,6 @@ AC_CACHE_CHECK([types of arguments for select],
   done
  done
 done
-# Provide a safe default value.
-: "${ac_cv_func_select_args=int,int *,struct timeval *}"
 ])
 ac_save_IFS=$IFS; IFS=','
 set dummy `echo "$ac_cv_func_select_args" | sed 's/\*/\*/g'`
diff --git a/lib/autoconf/programs.m4 b/lib/autoconf/programs.m4
index 087c913a..7f2d07f8 100644
--- a/lib/autoconf/programs.m4
+++ b/lib/autoconf/programs.m4
@@ -762,11 +762,14 @@ AS_VAR_SET_IF([LEXLIB], [], [
   AC_CACHE_CHECK([for lex library], [ac_cv_lib_lex], [
 ac_cv_lib_lex='not found'
 ac_save_LIBS=$LIBS
-for ac_lib in '' -lfl -ll; do
-  LIBS="$ac_lib $ac_save_LIBS"
+for ac_cv_lib_lex in 'none needed' -lfl -ll 'not found'; do
+  case $ac_cv_lib_lex in
+	'none needed') ;;
+	'not found') break;;
+	*) LIBS="$ac_lib $ac_save_LIBS";;
+  esac
   AC_LINK_IFELSE([AC_LANG_DEFINES_PROVIDED[`cat $LEX_OUTPUT_ROOT.c`]],
-	[ac_cv_lib_lex="${ac_lib:-none needed}"
- break])
+	[break])
 done
 LIBS=$ac_save_LIBS
   ])
diff --git a/lib/autotest/general.m4 b/lib/autotest/general.m4
index 5d89d0c0..6a6d1a47 100644
--- a/lib/autotest/general.m4
+++ b/lib/autotest/general.m4
@@ -1642,12 +1642,15 @@ else
   else
 at_msg="\`${at_testdir+${at_testdir}/}$as_me.log'"
   fi
+  at_msg1a=${at_xpass_list:+', '}
+  at_msg1=$at_fail_list${at_fail_list:+" failed$at_msg1a"}
+  at_msg2=$at_xpass_list${at_xpass_list:+" passed unexpectedly"}
+
   AS_ECHO(["Please send $at_msg and all information you think might help:
 
To: 
Subject: @<:@AT_PACKAGE_STRING@:>@ $as_me: dnl
-$at_fail_list${at_fail_list:+ failed${at_xpass_list:+, }}dnl
-$at_xpass_list${at_xpass_list:+ passed unexpectedly}
+$at_msg1$at_msg2
 
 You may investigate any problem if you feel able to do so, in which
 case the test suite provides a good starting point.  Its output may
-- 
2.17.1



Re: [PATCH] Revert 'Fix logic error in _AC_PROG_LEX_YYTEXT_DECL (#109320)'

2020-07-16 Thread Paul Eggert

On 7/16/20 12:42 PM, Ross Burton wrote:

checking for flex... flex
checking for lex output file root... lex.yy
checking for lex library... not found
configure: WARNING: required lex library not found; giving up on flex
...
configure: error: readline works only with flex.

Again, bc's scanner has its own yywrap implementation, so it doesn't
need to link to libfl.


In that case, why did 'configure' fail to build the little test program? The 
test program also has its own yywrap implementation, so it should be just like 
bc. 'configure' should successfully link the test program, set ac_cv_lib_lex to 
'none needed', and break out of the loop, and the warning you mentioned should 
not occur.


Are you using an old shell where 'ac_cv_lib_lex="${ac_lib:-none needed}' doesn't 
work? That might explain the problem.




Re: [PATCH] Revert 'Fix logic error in _AC_PROG_LEX_YYTEXT_DECL (#109320)'

2020-07-16 Thread Paul Eggert

On 7/16/20 10:34 AM, Ross Burton wrote:

Wouldn't that break cross-compilation where a host flex is present but
target libfl isn't?  That case worked previously and should work fine,
as libfl isn't actually that useful.


That shouldn't be a problem when building from tarballs, as flex shouldn't be 
needed then and the patch is a win because it prevents the build from failing 
unnecessarily. However, it could be a problem when building from Git 
repositories where you need flex but may well not need the library.


So I installed the attached patch, which implements Zack's first suggestion. I'm 
being somewhat bold in installing here; feel free to comment and suggest 
improvements (or suggest I revert :-).
>From 29ede6b96feee29c0c477d1659081bbdb82cd8b3 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 16 Jul 2020 10:39:56 -0700
Subject: [PATCH] AC_PROG_LEX no longer sets LEXLIB for yywrap

Suggested by Zack Weinberg in:
https://lists.gnu.org/r/autoconf-patches/2020-07/msg00016.html
* lib/autoconf/programs.m4 (_AC_PROG_LEX_YYTEXT_DECL):
Define yywrap too.
---
 NEWS |  4 
 doc/autoconf.texi| 13 +
 lib/autoconf/programs.m4 |  5 +
 3 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/NEWS b/NEWS
index 3c5dfec2..dd3b2896 100644
--- a/NEWS
+++ b/NEWS
@@ -104,6 +104,10 @@ GNU Autoconf NEWS - User visible changes.
 - AC_PROG_CC_STDC, AC_PROG_CC_C89, AC_PROG_CC_C99 have been marked as obsolete.
   Applications should use AC_PROG_CC.
 
+- AC_PROG_LEX no longer sets LEXLIB to be nonempty merely to define
+  the yywrap function.  Packages should define yywrap themselves, or
+  use %noyywrap.
+
 - AC_USE_SYSTEM_EXTENSIONS now enables more extensions on HP-UX,
   macOS, and MINIX, as well as on systems conforming to recent
   ISO/IEC C technical reports and specifications.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 379e3c2f..b8f889cc 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -4177,15 +4177,20 @@ The result of the test can be overridden by setting the variable
 @cvindex YYTEXT_POINTER
 @ovindex LEX_OUTPUT_ROOT
 @caindex prog_LEX
-If @code{flex} is found, set output variable @code{LEX} to @samp{flex}
-and @code{LEXLIB} to @option{-lfl}, if that library is in a standard
-place.  Otherwise set @code{LEX} to @samp{lex} and @code{LEXLIB} to
-@option{-ll}, if found.  If neither variant is available, set @code{LEX}
+If @code{flex} is found, set output variable @code{LEX} to @samp{flex}.
+Otherwise set @code{LEX} to @samp{lex}, if found.
+If neither variant is available, set @code{LEX}
 to @samp{:}; for packages that ship the generated @file{file.yy.c}
 alongside the source @file{file.l}, this default allows users without a
 lexer generator to still build the package even if the timestamp for
 @file{file.l} is inadvertently changed.
 
+If generated lexers need a library to work, set output variable
+@code{LEXLIB} to an option for that library (e.g., @option{-ll});
+otherwise define @code{LEXLIB} to empty.  A library that merely defines
+@code{main} and @code{yywrap} placeholder functions is not considered
+to be needed.
+
 Define @code{YYTEXT_POINTER} if @code{yytext} defaults to @samp{char *} instead
 of to @samp{char []}.  Also set output variable @code{LEX_OUTPUT_ROOT} to
 the base of the file name that the lexer generates; usually
diff --git a/lib/autoconf/programs.m4 b/lib/autoconf/programs.m4
index 4f910fb0..6fd44a3b 100644
--- a/lib/autoconf/programs.m4
+++ b/lib/autoconf/programs.m4
@@ -735,6 +735,11 @@ f { unput (yytext[0]); }
 extern char *yytext;
 #endif
 int
+yywrap (void)
+{
+  return 1;
+}
+int
 main (void)
 {
   return ! yylex () + ! yywrap ();
-- 
2.17.1



Re: [PATCH] Revert 'Fix logic error in _AC_PROG_LEX_YYTEXT_DECL (#109320)'

2020-07-16 Thread Paul Eggert

On 7/16/20 7:10 AM, Zack Weinberg wrote:


I propose to make the following additional changes, instead of reverting
the patch:

  - Change the conftest.l used by _AC_PROG_LEX_YYTEXT_DECL so that it
defines yywrap itself (it already defines main).  Thus, LEXLIB will
only be set to -ll or -lfl if there's something in there *besides*
yywrap and main that the generated scanner needs.  Document this.

  - Add a new macro, tentatively AC_FUNC_YYWRAP([action-if-not-found]),
that tries to find a definition of yywrap in libl and libfl, sets
LEXLIB accordingly, and failing that executes action-if-not-found,
which defaults to AC_LIBOBJ([yywrap]).

What do you think?


Unfortunately I read this email *after* looking at the bug reports on Savannah. 
(I *hate* having multiple streams of bug reports! Can't we standardize on just 
one? If it were up to me I'd stop using Savannah and stick with just 
bug-autoconf like the Autoconf manual says - but I digress.)


The patch I installed was simpler and more conservative than what you proposed. 
It gives up on 'flex' and sets LEX back to ":" if any of the 
_AC_PROG_LEX_YYTEXT_DECL tests fail.


I had not considered the fact that -lfl is basically useless. I like your first 
suggestion, as I expect it'll make AC_PROG_LEX more useful and will encourage 
people to stop linking with -lfl which is a good thing. I'm not sure that the 
AC_FUNC_YYWRAP macro would be worth the trouble.




Re: autoconf-2.69

2019-09-10 Thread Paul Eggert

On 9/10/19 1:25 AM, Ondrej Dubaj wrote:

Is everything OK with the patch?


Yes, it looks good. I installed it in autoconf master, after redoing the commit 
message to explain the patch in a bit more detail. Thanks for the patch.




Re: [PATCH] Improve argument quoting in config.log and config.status

2018-03-04 Thread Paul Eggert
Thanks, I like this patch. However, it's nontrivial enough that we'll need 
papers from you and your employer about it, since it's for a program that is in 
addition to the programs that we already have papers for. Could you please start 
the ball rolling on that? Thanks.




Re: update section about who uses autotest

2016-12-14 Thread Paul Eggert

Thanks, I installed that.



Re: [PATCH] AC_USE_SYSTEM_EXTENSIONS: port to recent ISO C

2016-09-15 Thread Paul Eggert

On 09/15/2016 11:08 AM, Joseph Myers wrote:

24747 is an International Standard, not a TR.


Thanks, fixed with the attached.

From 444debfb6cb4bbb96f1dee3210180a37c583a824 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 15 Sep 2016 12:26:26 -0700
Subject: [PATCH] AC_USE_SYSTEM_EXTENSIONS: Remove stray TR in doc

---
 doc/autoconf.texi| 2 +-
 lib/autoconf/specific.m4 | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 36e1938..4be1f70 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8677,7 +8677,7 @@ Enable extensions specified by ISO/IEC TS 18661-3:2015.
 Enable extensions specified by ISO/IEC TR 24731-2:2010.
 @item __STDC_WANT_MATH_SPEC_FUNCS__
 @cvindex __STDC_WANT_MATH_SPEC_FUNCS__
-Enable extensions specified by ISO/IEC TR 24747:2009.
+Enable extensions specified by ISO/IEC 24747:2009.
 @end table
 
 @cvindex __STDC_WANT_DEC_FP__
diff --git a/lib/autoconf/specific.m4 b/lib/autoconf/specific.m4
index db47fbb..5dfd85d 100644
--- a/lib/autoconf/specific.m4
+++ b/lib/autoconf/specific.m4
@@ -423,7 +423,7 @@ dnl configure.ac when using autoheader 2.62.
 #ifndef __STDC_WANT_LIB_EXT2__
 # undef __STDC_WANT_LIB_EXT2__
 #endif
-/* Enable extensions specified by ISO/IEC TR 24747:2009.  */
+/* Enable extensions specified by ISO/IEC 24747:2009.  */
 #ifndef __STDC_WANT_MATH_SPEC_FUNCS__
 # undef __STDC_WANT_MATH_SPEC_FUNCS__
 #endif
-- 
2.7.4



Re: [PATCH] AC_USE_SYSTEM_EXTENSIONS: port to recent ISO C

2016-09-15 Thread Paul Eggert
Thanks, I installed the attached additional patch to Autoconf master and 
plan to propagate this to Gnulib shortly.
From 0c416cdb46e719b68d8439a6e4436b50bf870176 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 15 Sep 2016 10:08:56 -0700
Subject: [PATCH] AC_USE_SYSTEM_EXTENSIONS: port to more ISO C TSes

* doc/autoconf.texi (C and Posix Variants): Rename from "Posix
Variants", and document updated behavior.
* lib/autoconf/specific.m4 (AC_USE_SYSTEM_EXTENSIONS): Also define
__STDC_WANT_IEC_60559_ATTRIBS_EXT__,
__STDC_WANT_IEC_60559_DFP_EXT__,
__STDC_WANT_IEC_60559_TYPES_EXT__, and
__STDC_WANT_MATH_SPEC_FUNCS__.  From a suggestion by Joseph Myers in:
http://lists.gnu.org/archive/html/autoconf-patches/2016-09/msg00011.html
---
 NEWS |  4 +--
 doc/autoconf.texi| 65 +++-
 lib/autoconf/specific.m4 | 20 +++
 3 files changed, 64 insertions(+), 25 deletions(-)

diff --git a/NEWS b/NEWS
index 43918bb..a4c53dd 100644
--- a/NEWS
+++ b/NEWS
@@ -59,8 +59,8 @@ GNU Autoconf NEWS - User visible changes.
   YFLAGS to enable these warnings.
 
 - AC_USE_SYSTEM_EXTENSIONS now enables more extensions on HP-UX,
-  macOS, and MINIX, as well as on systems conforming to ISO/IEC TR
-  24731-2:2010, ISO/IEC TS 18661-1:2014, and ISO/IEC TS 18661-4:2015.
+  macOS, and MINIX, as well as on systems conforming to recent
+  ISO/IEC C technical reports and specifications.
 
 - AC_CHECK_DECL and AC_CHECK_DECLS can now report missing declarations for
   functions that are also Clang compiler builtins.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 4f041bd..36e1938 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -363,7 +363,7 @@ Existing Tests
 * Types::   Types that might be missing
 * Compilers and Preprocessors::  Checking for compiling programs
 * System Services:: Operating system services
-* Posix Variants::  Special kludges for specific Posix variants
+* C and Posix Variants::Kludges for C and Posix variants
 * Erlang Libraries::Checking for the existence of Erlang libraries
 
 Common Behavior
@@ -3838,7 +3838,7 @@ Symbols}, for how to get those symbol definitions into your program.
 * Types::   Types that might be missing
 * Compilers and Preprocessors::  Checking for compiling programs
 * System Services:: Operating system services
-* Posix Variants::  Special kludges for specific Posix variants
+* C and Posix Variants::Kludges for C and Posix variants
 * Erlang Libraries::Checking for the existence of Erlang libraries
 @end menu
 
@@ -8606,29 +8606,16 @@ system.  If so, set the shell variable @code{ac_cv_sys_posix_termios} to
 @samp{yes}.  If not, set the variable to @samp{no}.
 @end defmac
 
-@node Posix Variants
-@section Posix Variants
+@node C and Posix Variants
+@section C and Posix Variants
 
-The following macro makes it possible to use features of Posix that are
-extensions to C, as well as platform extensions not defined by Posix.
+The following macro makes it possible to use C language and library
+extensions defined by the C standards committee, features of Posix that
+are extensions to C, and platform extensions not defined by Posix.
 
 @anchor{AC_USE_SYSTEM_EXTENSIONS}
 @defmac AC_USE_SYSTEM_EXTENSIONS
 @acindex{USE_SYSTEM_EXTENSIONS}
-@cvindex _GNU_SOURCE
-@cvindex _ALL_SOURCE
-@cvindex _DARWIN_C_SOURCE
-@cvindex _MINIX
-@cvindex _NETBSD_SOURCE
-@cvindex _POSIX_1_SOURCE
-@cvindex _POSIX_PTHREAD_SEMANTICS
-@cvindex _POSIX_SOURCE
-@cvindex _TANDEM_SOURCE
-@cvindex _XOPEN_SOURCE
-@cvindex __EXTENSIONS__
-@cvindex __STDC_WANT_IEC_60559_BFP_EXT__
-@cvindex __STDC_WANT_IEC_60559_FUNCS_EXT__
-@cvindex __STDC_WANT_LIB_EXT2__
 If possible, enable
 extensions to C or Posix on hosts that normally disable the extensions,
 typically due to standards-conformance namespace issues.  This should be
@@ -8637,42 +8624,74 @@ preprocessor macros are defined where appropriate:
 
 @table @code
 @item _GNU_SOURCE
+@cvindex _GNU_SOURCE
 Enable extensions on GNU/Linux.
 @item _ALL_SOURCE
+@cvindex _ALL_SOURCE
 Enable extensions for AIX 3, and for Interix.
 @item _DARWIN_C_SOURCE
+@cvindex _DARWIN_C_SOURCE
 Enable extensions for macOS.
 @item _MINIX
+@cvindex _MINIX
 Identify Minix platform.  This particular preprocessor macro is
 obsolescent, and may be removed in a future release of Autoconf.
 @item _NETBSD_SOURCE
+@cvindex _NETBSD_SOURCE
 Enable NetBSD-related extensions for Minix.
 @item _POSIX_1_SOURCE
+@cvindex _POSIX_1_SOURCE
 Enable additional Posix functions for Minix.
 @item _POSIX_PTHREAD_SEMANTICS
+@cvindex _POSIX_PTHREAD_SEMANTICS
 Enable threading extensions on Solaris.
 @item _POSIX_SOURCE
+@cvindex _POSIX_SOURCE
 Enable Posix functions for Minix.
 @item _TANDEM_SOURCE
+@cvindex _TANDEM_SOURCE
 Enable extensions for the HP NonStop platform.
 @item _XOPEN_SOURCE
+@cvindex _XOPEN_SOURCE

Re: bogus "Negative repeat count does nothing" warnings on Autoconf manual

2016-09-14 Thread Paul Eggert
Thanks for the diagnosis. I installed the attached workaround into 
Autoconf to work around the problem, as unfixed Texinfo versions will be 
around for a while.
From d3a4cccfe8807c7354ef6edd2913362d34d8e574 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Wed, 14 Sep 2016 12:14:45 -0700
Subject: [PATCH] doc: resplit lines to avoid Texinfo chaos

* doc/autoconf.texi (Introduction): Resplit lines to avoid
Texinfo 6.3 incompatibility with Perl 5.22.  See:
http://lists.gnu.org/archive/html/bug-texinfo/2016-09/msg00037.html
---
 doc/autoconf.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index d3ccf19..9ad7dc1 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -693,8 +693,8 @@ nature of God.  ``Surely a Physicist,'' said the physicist, ``because
 early in the Creation, God made Light; and you know, Maxwell's
 equations, the dual nature of electromagnetic waves, the relativistic
 consequences@enddots{}'' ``An Engineer!,'' said the engineer, ``because
-before making Light, God split the Chaos into Land and Water; it takes a
-hell of an engineer to handle that big amount of mud, and orderly
+before making Light, God split the Chaos into Land and Water; it takes
+a hell of an engineer to handle that big amount of mud, and orderly
 separation of solids from liquids@enddots{}'' The computer scientist
 shouted: ``And the Chaos, where do you think it was coming from, hmm?''
 
-- 
2.7.4



Re: [PATCH] AC_USE_SYSTEM_EXTENSIONS: port to recent ISO C

2016-09-14 Thread Paul Eggert

On 09/14/2016 05:55 AM, Joseph Myers wrote:

Why not __STDC_WANT_IEC_60559_TYPES_EXT__ (which makes GCC 7's 
declare limits for _FloatN and _FloatNx types; not yet anything in glibc,
until the float128 work is in)?


Sorry, I didn't know about __STDC_WANT_IEC_60559_TYPES_EXT__. I don't 
have access to the recent ISO C standards documents, which are not free.



(There are other feature test macros for
ISO C extensions as well.)


Thanks, is there a list of these new macros somewhere? I might as well 
add them all now.





[PATCH] AC_USE_SYSTEM_EXTENSIONS: port to recent ISO C

2016-09-13 Thread Paul Eggert
* lib/autoconf/specific.m4 (AC_USE_SYSTEM_EXTENSIONS):
Also define __STDC_WANT_IEC_60559_BFP_EXT__,
__STDC_WANT_IEC_60559_FUNCS_EXT__, and __STDC_WANT_LIB_EXT2__.
* NEWS, doc/autoconf.texi (Posix Variants):
Document this.  Also, document other changes in this area
that were not properly documented before.
---
 NEWS |  5 +++--
 doc/autoconf.texi| 49 
 lib/autoconf/specific.m4 | 17 -
 3 files changed, 56 insertions(+), 15 deletions(-)

diff --git a/NEWS b/NEWS
index 5f05ad6..43918bb 100644
--- a/NEWS
+++ b/NEWS
@@ -58,8 +58,9 @@ GNU Autoconf NEWS - User visible changes.
   by default it no longer warns about Bison extensions.  Add -Wyacc to
   YFLAGS to enable these warnings.
 
-- AC_USE_SYSTEM_EXTENSIONS now enables more system extensions on HP-UX,
-  MINIX 3, and OS X.
+- AC_USE_SYSTEM_EXTENSIONS now enables more extensions on HP-UX,
+  macOS, and MINIX, as well as on systems conforming to ISO/IEC TR
+  24731-2:2010, ISO/IEC TS 18661-1:2014, and ISO/IEC TS 18661-4:2015.
 
 - AC_CHECK_DECL and AC_CHECK_DECLS can now report missing declarations for
   functions that are also Clang compiler builtins.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index ddbeddf..d3ccf19 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8588,15 +8588,21 @@ extensions to C, as well as platform extensions not 
defined by Posix.
 @anchor{AC_USE_SYSTEM_EXTENSIONS}
 @defmac AC_USE_SYSTEM_EXTENSIONS
 @acindex{USE_SYSTEM_EXTENSIONS}
-@cvindex _ALL_SOURCE
 @cvindex _GNU_SOURCE
+@cvindex _ALL_SOURCE
+@cvindex _DARWIN_C_SOURCE
 @cvindex _MINIX
+@cvindex _NETBSD_SOURCE
 @cvindex _POSIX_1_SOURCE
 @cvindex _POSIX_PTHREAD_SEMANTICS
 @cvindex _POSIX_SOURCE
 @cvindex _TANDEM_SOURCE
+@cvindex _XOPEN_SOURCE
 @cvindex __EXTENSIONS__
-This macro was introduced in Autoconf 2.60.  If possible, enable
+@cvindex __STDC_WANT_IEC_60559_BFP_EXT__
+@cvindex __STDC_WANT_IEC_60559_FUNCS_EXT__
+@cvindex __STDC_WANT_LIB_EXT2__
+If possible, enable
 extensions to C or Posix on hosts that normally disable the extensions,
 typically due to standards-conformance namespace issues.  This should be
 called before any macros that run the C compiler.  The following
@@ -8605,22 +8611,41 @@ preprocessor macros are defined where appropriate:
 @table @code
 @item _GNU_SOURCE
 Enable extensions on GNU/Linux.
-@item __EXTENSIONS__
-Enable general extensions on Solaris.
-@item _POSIX_PTHREAD_SEMANTICS
-Enable threading extensions on Solaris.
-@item _TANDEM_SOURCE
-Enable extensions for the HP NonStop platform.
 @item _ALL_SOURCE
 Enable extensions for AIX 3, and for Interix.
-@item _POSIX_SOURCE
-Enable Posix functions for Minix.
-@item _POSIX_1_SOURCE
-Enable additional Posix functions for Minix.
+@item _DARWIN_C_SOURCE
+Enable extensions for macOS.
 @item _MINIX
 Identify Minix platform.  This particular preprocessor macro is
 obsolescent, and may be removed in a future release of Autoconf.
+@item _NETBSD_SOURCE
+Enable NetBSD-related extensions for Minix.
+@item _POSIX_1_SOURCE
+Enable additional Posix functions for Minix.
+@item _POSIX_PTHREAD_SEMANTICS
+Enable threading extensions on Solaris.
+@item _POSIX_SOURCE
+Enable Posix functions for Minix.
+@item _TANDEM_SOURCE
+Enable extensions for the HP NonStop platform.
+@item _XOPEN_SOURCE
+Enable X/Open extensions for HP-UX.
+@item __EXTENSIONS__
+Enable general extensions on Solaris.
+@item __STDC_WANT_IEC_60559_BFP_EXT__
+Enable extensions specified by ISO/IEC TS 18661-1:2014.
+@item __STDC_WANT_IEC_60559_FUNCS_EXT__
+Enable extensions specified by ISO/IEC TS 18661-4:2015.
+@item __STDC_WANT_LIB_EXT2__
+Enable extensions specified by ISO/IEC TR 24731-2:2010.
 @end table
+
+The macro @code{__STDC_WANT_LIB_EXT1__} is not defined, as C11 Annex K
+is problematic.  See: O'Donell C, Sebor M.
+@uref{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm, Field
+Experience With Annex K---Bounds Checking Interfaces}.
+
+This macro was introduced in Autoconf 2.60.
 @end defmac
 
 
diff --git a/lib/autoconf/specific.m4 b/lib/autoconf/specific.m4
index e665b90..ad77be8 100644
--- a/lib/autoconf/specific.m4
+++ b/lib/autoconf/specific.m4
@@ -387,7 +387,7 @@ dnl configure.ac when using autoheader 2.62.
 #ifndef _ALL_SOURCE
 # undef _ALL_SOURCE
 #endif
-/* Enable general extensions on OS X.  */
+/* Enable general extensions on macOS.  */
 #ifndef _DARWIN_C_SOURCE
 # undef _DARWIN_C_SOURCE
 #endif
@@ -399,6 +399,18 @@ dnl configure.ac when using autoheader 2.62.
 #ifndef _POSIX_PTHREAD_SEMANTICS
 # undef _POSIX_PTHREAD_SEMANTICS
 #endif
+/* Enable extensions specified by ISO/IEC TS 18661-1:2014.  */
+#ifndef __STDC_WANT_IEC_60559_BFP_EXT__
+# undef __STDC_WANT_IEC_60559_BFP_EXT__
+#endif
+/* Enable extensions specified by ISO/IEC TS 18661-4:2015.  */
+#ifndef __STDC_WANT_IEC_60559_FUNCS_EXT__
+# undef __STDC_WANT_IEC_60559_FUNCS_EXT__
+#endif
+/* Enable extensions specified by ISO/IEC TR 24731-2:2010.  */
+#ifndef __STDC_WANT_LIB

[PATCH] doc: port to Texinfo 6.3

2016-09-13 Thread Paul Eggert
* doc/autoconf.texi: Remove obsolete @setcontentsaftertitlepage
that provokes a warning from Texinfo 6.3.
---
 doc/autoconf.texi | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 029ddd6..ddbeddf 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -6,9 +6,6 @@
 @settitle Autoconf
 @documentencoding UTF-8
 @setchapternewpage odd
-@ifnothtml
-@setcontentsaftertitlepage
-@end ifnothtml
 @finalout
 
 @c @ovar(ARG)
-- 
2.7.4




Re: [PATCH] Amend AC_CHECK_HEADER_STDBOOL for C++11 and modern dialects

2016-05-31 Thread Paul Eggert

On 05/31/2016 12:33 AM, David Seifert wrote:

configure.ac:

AC_INIT
AC_PROG_CXX
m4_include([stdbool.m4])
AC_LANG_PUSH([C++])
AC_CHECK_HEADER_STDBOOL


Thanks for the example. I installed your patch into gnulib. But I don't 
see how it can work without __bool_true_false_are_defined being defined, 
so I installed the attached additional patch as well. Please let us know 
if you see a problem with this.


CC:ing autoconf-patches@gnu.org since I installed a patch there too, to 
match.


From cb7476a1db148980b8cff02824774598ffaea8ce Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Tue, 31 May 2016 09:03:15 -0700
Subject: [PATCH] stdbool: Restore __bool_true_false_are_defined check

* m4/stdbool.m4 (AC_CHECK_HEADER_STDBOOL):
__bool_true_false_are_defined is still defined, even with C++11.
---
 ChangeLog | 6 ++
 m4/stdbool.m4 | 9 +
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 02a7c86..a6df98a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2016-05-31  Paul Eggert  
+
+	stdbool: Restore __bool_true_false_are_defined check
+	* m4/stdbool.m4 (AC_CHECK_HEADER_STDBOOL):
+	__bool_true_false_are_defined is still defined, even with C++11.
+
 2016-05-31  David Seifert   (tiny change)
 
 	stdbool: Port AC_CHECK_HEADER_STDBOOL to C++11
diff --git a/m4/stdbool.m4 b/m4/stdbool.m4
index 0863847..a556153 100644
--- a/m4/stdbool.m4
+++ b/m4/stdbool.m4
@@ -44,7 +44,7 @@ AC_DEFUN([AC_CHECK_HEADER_STDBOOL],
[[
  #include 
 
- #if __cplusplus < 201103L
+ #if __cplusplus < 201103
   #ifndef bool
"error: bool is not defined"
   #endif
@@ -60,9 +60,10 @@ AC_DEFUN([AC_CHECK_HEADER_STDBOOL],
   #if true != 1
"error: true is not 1"
   #endif
-  #ifndef __bool_true_false_are_defined
-   "error: __bool_true_false_are_defined is not defined"
-  #endif
+ #endif
+
+ #ifndef __bool_true_false_are_defined
+  "error: __bool_true_false_are_defined is not defined"
  #endif
 
  struct s { _Bool s: 1; _Bool t; } s;
-- 
2.5.5



Re: PATCH: remove config.{guess,sub} man pages

2016-02-06 Thread Paul Eggert

Ben Elliston wrote:


https://lists.gnu.org/archive/html/autoconf-patches/2015-11/msg0.html


Thanks, I installed that.




Re: [PATCH] m4_set_foreach: pop macro definition

2015-04-20 Thread Paul Eggert

Thanks for the fix; I installed it.



Re: [PATCH] Replace 'test "${var+set}" = set' with 'test -n "${var+set}"'

2015-04-08 Thread Paul Eggert

Eric Blake wrote:

test ${var+y}


Hah!  Here's something that's one byte shorter:

${var+:} [ ]

It may be clearer to write it more in the style you used:

[ ${var+y} ]

Both of these work with Solaris 10 /bin/sh.



Re: [PATCH] Replace 'test "${var+set}" = set' with 'test -n "${var+set}"'

2015-04-08 Thread Paul Eggert

Isn't '${var+:} false' faster yet?



Re: [Emacs-diffs] master 2534676 2/2: Simplify setfattr use by assuming GNU make

2015-01-02 Thread Paul Eggert

On 01/02/2015 11:12 AM, Glenn Morris wrote:

The autoconf manual says "Don't rely on ln having a -f option."


Although that was good advice in the early 1990s when that part of the 
Autoconf manual was written, the advice has been obsolete for years.  I 
installed the attached patch into Autoconf to fix this (after bumping 
Autoconf's copyright year).  I'm CC:ing this to autoconf-patches.
>From 4774ff5c33d34bb6ad21c06f3c2b54d6e700740e Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Fri, 2 Jan 2015 13:02:48 -0800
Subject: [PATCH] doc: -f is now portable for cp and ln

This follows up on a comment by Glenn Morris in:
http://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00011.html
* doc/autoconf.texi (Limitations of Usual Tools):
Remove circa-1990 advice about avoiding cp -f and ln -f.
Although that advice was reasonable for the early 1990s, the -f
option is portable for both cp and ln nowadays.  These options
were standardized in POSIX 1003.2-1992, and pre-POSIX systems such
as SunOS 4 are no longer of practical concern.
---
 doc/autoconf.texi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 639cec2..d9e833d 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -18684,9 +18684,7 @@ avoid this problem, omit the trailing slashes.  For example, use
 @samp{cp -R source /tmp/newdir} rather than @samp{cp -R source
 /tmp/newdir/} if @file{/tmp/newdir} does not exist.
 
-@c This is thanks to Ian.
-The ancient SunOS 4 @command{cp} does not support @option{-f}, although
-its @command{mv} does.
+The @option{-f} option is portable nowadays.
 
 @cindex timestamp resolution
 Traditionally, file timestamps had 1-second resolution, and @samp{cp
@@ -19088,9 +19086,11 @@ the workaround is to use @command{join -a1 file1 file2} instead.
 @item @command{ln}
 @c ---
 @prindex @command{ln}
+The @option{-f} option is portable nowadays.
+
 @cindex Symbolic links
-Don't rely on @command{ln} having a @option{-f} option.  Symbolic links
-are not available on old systems; use @samp{$(LN_S)} as a portable substitute.
+Symbolic links are not available on some systems; use @samp{$(LN_S)} as
+a portable substitute.
 
 For versions of the DJGPP before 2.04,
 @command{ln} emulates symbolic links
-- 
2.1.0



Re: AC_FLAGS_WARN_ALL changes proposed for inclusion in next autoconf release

2014-09-13 Thread Paul Eggert

David A. Wheeler wrote:

Dale's code is derived from previous FSF code, so I think all the copyright 
issues are addressed.


That would be true only if Dale's changes, taken as a whole, are 
trivial; our rule of thumb for that is about 10 lines of reasonably 
obvious changes.


Also, as I understand it, other people contributed.

I haven't looked into the details, though.



Re: AC_FLAGS_WARN_ALL changes proposed for inclusion in next autoconf release

2014-09-05 Thread Paul Eggert

Thanks for getting the ball rolling on this.  A couple of thoughts.

First, how does this compare to the warnings and manywarnings modules of 
Gnulib?  They seem to do something similar.  See:


http://www.gnu.org/software/gnulib/manual/html_node/warnings.html

http://www.gnu.org/software/gnulib/manual/html_node/manywarnings.html

Second, from a brief look at the patch it appears that it is derived 
from code that other people have written, which would mean we'd need to 
get copyright papers from them too.





[PATCH] autoconf: fix typo in previous change

2014-09-02 Thread Paul Eggert
* lib/autoconf/c.m4 (AC_C_RESTRICT): Fix typo in previous change.
---
 lib/autoconf/c.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index a565339..9b7aa6b 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -1862,7 +1862,7 @@ AC_DEFUN([AC_C_RESTRICT],
 [[typedef int *int_ptr;
   int foo (int_ptr $ac_kw ip) { return ip[0]; }
   int bar (int [$ac_kw]); /* Catch GCC bug 14050.  */
-  int bar (int [$ac_kw ip]) { return ip[0]; }
+  int bar (int ip[$ac_kw]) { return ip[0]; }
 ]],
 [[int s[1];
   int *$ac_kw t = s;
-- 
1.9.3




[PATCH] autoconf: port 'restrict' to GCC 4.2.1

2014-09-02 Thread Paul Eggert
* lib/autoconf/c.m4 (AC_C_RESTRICT): Detect GCC bug 14050.
Problem reported by Marco Munari for OpenBSD 5.5.
---
 lib/autoconf/c.m4 | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index a944529..a565339 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -1853,19 +1853,22 @@ fi
 # Otherwise, define "restrict" to be empty.
 AN_IDENTIFIER([restrict], [AC_C_RESTRICT])
 AC_DEFUN([AC_C_RESTRICT],
-[AC_CACHE_CHECK([for C/C++ restrict keyword], ac_cv_c_restrict,
+[AC_CACHE_CHECK([for C/C++ restrict keyword], [ac_cv_c_restrict],
   [ac_cv_c_restrict=no
# The order here caters to the fact that C++ does not require restrict.
for ac_kw in __restrict __restrict__ _Restrict restrict; do
- AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
-  [[typedef int * int_ptr;
-   int foo (int_ptr $ac_kw ip) {
-   return ip[0];
-   }]],
-  [[int s[1];
-   int * $ac_kw t = s;
-   t[0] = 0;
-   return foo(t)]])],
+ AC_COMPILE_IFELSE(
+  [AC_LANG_PROGRAM(
+[[typedef int *int_ptr;
+  int foo (int_ptr $ac_kw ip) { return ip[0]; }
+  int bar (int [$ac_kw]); /* Catch GCC bug 14050.  */
+  int bar (int [$ac_kw ip]) { return ip[0]; }
+]],
+[[int s[1];
+  int *$ac_kw t = s;
+  t[0] = 0;
+  return foo (t) + bar (t);
+]])],
   [ac_cv_c_restrict=$ac_kw])
  test "$ac_cv_c_restrict" != no && break
done
-- 
1.9.3




[PATCH 3/3] autoconf: modernize AC_C_VARARRAYS for C11

2014-08-07 Thread Paul Eggert
* lib/autoconf/c.m4 (AC_C_VARARRAYS): Define __STDC_NO_VLA__ if
VLAs are not supported, as this is what C11 does.  The old macro
HAVE_C_VARARRAYS is still defined if they are supported, but is
now obsolescent.  Also, check for VLA bug in GCC 3.4.3.
* doc/autoconf.texi (C Compiler), NEWS: Document the above.
---
 NEWS  |  6 ++
 doc/autoconf.texi | 12 
 lib/autoconf/c.m4 | 52 ++--
 3 files changed, 60 insertions(+), 10 deletions(-)

diff --git a/NEWS b/NEWS
index 3f66825..6e2aabd 100644
--- a/NEWS
+++ b/NEWS
@@ -31,6 +31,12 @@ GNU Autoconf NEWS - User visible changes.
 
 - New macro AC_C__GENERIC.
 
+- AC_C_VARARRAYS now defines __STDC_NO_VLA__ if variable-length
+  arrays are not supported and if the compiler does not already
+  define __STDC_NO_VLA__.  This is for compatibility with C11.
+  For backward compatibility with Autoconf 2.61-2.69 AC_C_VARARRAYS
+  still defines HAVE_C_VARARRAYS, but this usage is obsolescent.
+
 - AC_CONFIG_MACRO_DIRS
   New macro, used to declare multiple directories when looking for
   local M4 macros.  This macro overcomes some of the shortfalls in the
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 791436b..83e6643 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -7488,11 +7488,15 @@ for (i = 0; i < n; i++)
 
 @defmac AC_C_VARARRAYS
 @acindex{C_VARARRAYS}
+@cvindex __STDC_NO_VLA__
 @cvindex HAVE_C_VARARRAYS
-If the C compiler supports variable-length arrays, define
-@code{HAVE_C_VARARRAYS}.  A variable-length array is an array of automatic
-storage duration whose length is determined at run time, when the array
-is declared.
+If the C compiler does not support variable-length arrays, define the
+macro @code{__STDC_NO_VLA__} to be 1 if it is not already defined.  A
+variable-length array is an array of automatic storage duration whose
+length is determined at run time, when the array is declared.  For
+backward compatibility this macro also defines @code{HAVE_C_VARARRAYS}
+if the C compiler supports variable-length arrays, but this usage is
+obsolescent and new programs should use @code{__STDC_NO_VLA__}.
 @end defmac
 
 @defmac AC_C_TYPEOF
diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index b58e42d..a944529 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -1995,14 +1995,54 @@ AC_DEFUN([AC_C_VARARRAYS],
 [
   AC_CACHE_CHECK([for variable-length arrays],
 ac_cv_c_vararrays,
-[AC_COMPILE_IFELSE(
-   [AC_LANG_PROGRAM([],
- [[static int x; char a[++x]; a[sizeof a - 1] = 0; return a[0];]])],
-   [ac_cv_c_vararrays=yes],
-   [ac_cv_c_vararrays=no])])
-  if test $ac_cv_c_vararrays = yes; then
+[AC_EGREP_CPP([defined],
+   [#ifdef __STDC_NO_VLA__
+   defined
+   #endif
+   ],
+   [ac_cv_c_vararrays='no: __STDC_NO_VLA__ is defined'],
+   [AC_COMPILE_IFELSE(
+ [AC_LANG_PROGRAM(
+[[/* Test for VLA support.  This test is partly inspired
+ from examples in the C standard.  Use at least two VLA
+ functions to detect the GCC 3.4.3 bug described in:
+ 
http://lists.gnu.org/archive/html/bug-gnulib/2014-08/msg00014.html
+ */
+  #ifdef __STDC_NO_VLA__
+   syntax error;
+  #else
+extern int n;
+int B[100];
+int fvla (int m, int C[m][m]);
+
+int
+simple (int count, int all[static count])
+{
+  return all[count - 1];
+}
+
+int
+fvla (int m, int C[m][m])
+{
+  typedef int VLA[m][m];
+  VLA x;
+  int D[m];
+  static int (*q)[m] = &B;
+  int (*s)[n] = q;
+  return C && &x[0][0] == &D[0] && &D[0] == s[0];
+}
+  #endif
+  ]])],
+ [ac_cv_c_vararrays=yes],
+ [ac_cv_c_vararrays=no])])])
+  if test "$ac_cv_c_vararrays" = yes; then
+dnl This is for compatibility with Autoconf 2.61-2.69.
 AC_DEFINE([HAVE_C_VARARRAYS], 1,
   [Define to 1 if C supports variable-length arrays.])
+  elif test "$ac_cv_c_vararrays" = no; then
+AC_DEFINE([__STDC_NO_VLA__], 1,
+  [Define to 1 if C does not support variable-length arrays, and
+   if the compiler does not already define this.])
   fi
 ])
 
-- 
1.9.3




[PATCH 2/3] doc: Solaris 11 supports $(...)

2014-08-07 Thread Paul Eggert
* doc/autoconf.texi (Shell Substitutions): Say that $(...) isn't
working in Solaris 10 and earlier, not in "recent releases".
---
 doc/autoconf.texi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 9dce296..791436b 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -16379,12 +16379,12 @@ and it has most of the problems listed under 
@code{`@var{commands}`}.
 
 This construct can be
 nested while this is impossible to do portably with back quotes.
-Unfortunately it is not yet universally supported.  Most notably, even recent
-releases of Solaris don't support it:
+Although it is almost universally supported, unfortunately Solaris 10
+and earlier releases lack it:
 
 @example
 $ @kbd{showrev -c /bin/sh | grep version}
-Command version: SunOS 5.10 Generic 121005-03 Oct 2006
+Command version: SunOS 5.10 Generic 142251-02 Sep 2010
 $ @kbd{echo $(echo blah)}
 syntax error: `(' unexpected
 @end example
-- 
1.9.3




[PATCH 1/3] doc: modernize character encoding

2014-08-07 Thread Paul Eggert
* doc/autoconf.texi: Specify @documentencoding UTF-8.  Don't abuse
'`' to mean open quote, unless Texinfo already interprets it that
way.  Be more careful about hyphen versus minus versus endash
versus emdash.
---
 doc/autoconf.texi | 51 ++-
 1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 4a4ee81..9dce296 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -4,6 +4,7 @@
 @setfilename autoconf.info
 @include version.texi
 @settitle Autoconf
+@documentencoding UTF-8
 @setchapternewpage odd
 @ifnothtml
 @setcontentsaftertitlepage
@@ -39,16 +40,16 @@
 @c Because we want to drop out the AC_ part of the macro names in the
 @c printed manual, but not in the other outputs, we need a layer above
 @c the usual @acindex{} etc.  That's why we first define indexes such as
-@c acx meant to become the macro @acindex.  First of all, using ``ac_''
-@c does not work with makeinfo, and using ``ac1'' doesn't work with TeX.
-@c So use something more regular ``acx''.  Then you finish with a printed
-@c index saying ``index is not existent''.  Of course: you ought to use
+@c acx meant to become the macro @acindex.  First of all, using 'ac_'
+@c does not work with makeinfo, and using 'ac1' doesn't work with TeX.
+@c So use something more regular 'acx'.  Then you finish with a printed
+@c index saying 'index is not existent'.  Of course: you ought to use
 @c two letters :(  So you use capitals.
 @c
 @c Second, when defining a macro in the TeX world, following spaces are
 @c eaten.  But then, since we embed @acxindex commands that use the end
 @c of line as an end marker, the whole things wrecks itself.  So make
-@c sure you do *force* an additional end of line, add a ``@c''.
+@c sure you do *force* an additional end of line, add a '@c'.
 @c
 @c Finally, you might want to get rid of TeX expansion, using --expand
 @c with texi2dvi.  But then you wake up an old problem: we use macros
@@ -72,7 +73,7 @@
 @defcodeindex AT
 @c Define an M4sugar macro index that @defmac doesn't write to.
 @defcodeindex MS
-@c Define an index for *foreign* programs: `mv' etc.  Used for the
+@c Define an index for *foreign* programs: 'mv' etc.  Used for the
 @c portability sections and so on.
 @defindex pr
 
@@ -210,7 +211,7 @@ This manual (@value{UPDATED}) is for GNU Autoconf
 a package for creating scripts to configure source code packages using
 templates and an M4 macro package.
 
-Copyright @copyright{} 1992-1996, 1998-2014 Free Software Foundation,
+Copyright @copyright{} 1992--1996, 1998--2014 Free Software Foundation,
 Inc.
 
 @quotation
@@ -742,7 +743,7 @@ along that front are welcome, since package maintainers 
form the user
 base of Autoconf); rather, the goal is to make @file{configure}
 painless, portable, and predictable for the end user of each
 @dfn{autoconfiscated} package.  And to this degree, Autoconf is highly
-successful at its goal --- most complaints to the Autoconf list are
+successful at its goal---most complaints to the Autoconf list are
 about difficulties in writing Autoconf input, and not in the behavior of
 the resulting @file{configure}.  Even packages that don't use Autoconf
 will generally provide a @file{configure} script, and the most common
@@ -6503,7 +6504,7 @@ If no @var{includes} are specified, the default includes 
are used
 
 @example
 AC_CHECK_MEMBER([struct passwd.pw_gecos], [],
-[AC_MSG_ERROR([we need `passwd.pw_gecos'])],
+[AC_MSG_ERROR([we need 'passwd.pw_gecos'])],
 [[#include ]])
 @end example
 
@@ -9875,11 +9876,11 @@ different things.
 @example
 $ @kbd{./configure --silent --config-cache}
 $ @kbd{CC=cc ./configure --silent --config-cache}
-configure: error: `CC' was not set in the previous run
+configure: error: 'CC' was not set in the previous run
 configure: error: changes in the environment can compromise \
 the build
-configure: error: run `make distclean' and/or \
-`rm config.cache' and start over
+configure: error: run 'make distclean' and/or \
+'rm config.cache' and start over
 @end example
 
 @noindent
@@ -9990,7 +9991,7 @@ AC_DEFUN([AC_SHELL_TRUE],
  (true) 2>/dev/null && my_cv_shell_true_works=yes
  if test "x$my_cv_shell_true_works" = xyes; then
AC_DEFINE([TRUE_WORKS], [1],
- [Define if `true(1)' works properly.])
+ [Define if 'true(1)' works properly.])
  fi])
 ])
 @end group
@@ -10010,7 +10011,7 @@ AC_DEFUN([AC_SHELL_TRUE],
  (true) 2>/dev/null && my_cv_shell_true_works=yes])
  if test "x$my_cv_shell_true_works" = xyes; then
AC_DEFINE([TRUE_WORKS], [1],
- [Define if `true(1)' works properly.])
+ [Define if 'true(1)' works properly.])
  fi
 ])
 @end group
@@ -10708,7 +10709,7 @@ the one they were implemented with.
 @cindex quadrigraphs
 @cindex @samp{@@S|@@}
 @cindex @samp

  1   2   3   4   5   6   7   8   9   10   >