[PATCH] intprops: document fix for GCC bug 68193

2024-04-30 Thread Paul Eggert
* lib/intprops-internal.h (_GL__GENERIC_BOGUS):
GCC bug 68193 is fixed in GCC 14.  This is just for documentation,
as _GL__GENERIC_BOGUS is not consulted in GCC 14.
---
 ChangeLog   | 7 +++
 lib/intprops-internal.h | 4 ++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index bf68bf6369..e2c736f854 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2024-04-30  Paul Eggert  
+
+   intprops: document fix for GCC bug 68193
+   * lib/intprops-internal.h (_GL__GENERIC_BOGUS):
+   GCC bug 68193 is fixed in GCC 14.  This is just for documentation,
+   as _GL__GENERIC_BOGUS is not consulted in GCC 14.
+
 2024-04-30  Bruno Haible  
 
*printf: Don't invoke gl_PRINTF_DIRECTIVE_N when it's not needed.
diff --git a/lib/intprops-internal.h b/lib/intprops-internal.h
index b5ba8d7cbd..443024c665 100644
--- a/lib/intprops-internal.h
+++ b/lib/intprops-internal.h
@@ -185,10 +185,10 @@
 /* Nonzero if this compiler has GCC bug 68193 or Clang bug 25390.  See:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193
https://llvm.org/bugs/show_bug.cgi?id=25390
-   For now, assume all versions of GCC-like compilers generate bogus
+   For now, assume GCC < 14 and all Clang versions generate bogus
warnings for _Generic.  This matters only for compilers that
lack relevant builtins.  */
-#if __GNUC__ || defined __clang__
+#if (__GNUC__ && __GNUC__ < 14) || defined __clang__
 # define _GL__GENERIC_BOGUS 1
 #else
 # define _GL__GENERIC_BOGUS 0
-- 
2.44.0




Re: test-sprintf-posix and test-snprintf-posix test failures

2024-04-30 Thread Collin Funk
Hi Bruno,

On 4/28/24 2:11 AM, Bruno Haible wrote:
> Correct. I added a comment, because the situation in ISO C and POSIX has
> changed, not too long ago.

It took me a bit to understand what was happening. Thanks for the
explination. I'm glad the standard has changed to accomodate with
glibc and others already did.

> Perfect! Thank you. You also found out in which corner of GCC the faulty
> optimization lies!

Yeah, I had a fun time exploring some of gcc. :)

Since the bug exists from GCC 7.1 ("starts from" on the report) to GCC
15, should those two test cases be updated? Maybe an '#if ...' or even
just a comment so it isn't reported as a new bug in the future.

Thanks.

Collin



Re: OSError: [WinError 193] %1 is not a valid Win32 application

2024-04-30 Thread Collin Funk
On 4/30/24 6:44 AM, Bruno Haible wrote:
> Collin: Before you just apply this patch, two notes:
> * The patch is a pessimization on Unix systems, since executing with
>   shell=True is slower than without.
> * We have basically three ways to deal with this (that I can see):
>   a) Update the requirements and say that a Cygwin environment with a
>  Cygwin-based Python build is required. (I tested that; so, we know
>  that works.)
>   b) Change the gnulib-tool entry-point script to prefer the shell-based
>  implementation if the host OS, as viewed from Python, is native
>  Windows (not Cygwin).
>   c) Port gnulib-tool.py to native Windows.
>   Your choice.

Ideally, it would probably be best to get gnulib-tool.py to work on
Windows. Since Python should do all the heavy lifting in that area.

However, you mentioned previously that it has it's own issues with
Autotools and such. Since it isn't free, I assume that anything there
is "best effort" for the most part.

You make a good point about shell=True being slower. I wonder if it is
even necessary here. When I see this error message:

 OSError: [WinError 193] %1 is not a valid Win32 application

I assume that windows doesn't do anything about the '#!/bin/sh' line.
Maybe placing the shell as argv[0] in sp.run would fix it? I'm not too
sure where that is typically installed on Windows though...

Collin



Re: OSError: [WinError 193] %1 is not a valid Win32 application

2024-04-30 Thread Bruno Haible
Hi, 

Jianshan Jiang wrote:
>  I use the newest version of gnulib from git. when I run the
> ./autogen.sh where I create for sed-4.9. gnulib-tool will throw an
> exception like below:
> ...
>   File "C:\Python312\Lib\subprocess.py", line 1538, in _execute_child
> hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
>^^^
> OSError: [WinError 193] %1 is not a valid Win32 application

Two questions and one suggestion:

1) You're apparently using Windows and can execute shell scripts.
   Which environment are you using for doing so? Cygwin? MSYS2? Other?

2) Why are you spending time to write an autogen.sh script for sed,
   when the README-hacking file recommends to use the 'bootstrap'
   script for the same purpose?

And a suggestion: What if you set the environment variable
GNULIB_TOOL_IMPL=sh ? Does your autogen.sh work then?

> Finally, I have found the solution. I have add the 'shell=True' into
> function sp.run in GLImport.py. You can see the detail
> in 001-gnulib-fix-WinError-193.diff.

Collin: Before you just apply this patch, two notes:
* The patch is a pessimization on Unix systems, since executing with
  shell=True is slower than without.
* We have basically three ways to deal with this (that I can see):
  a) Update the requirements and say that a Cygwin environment with a
 Cygwin-based Python build is required. (I tested that; so, we know
 that works.)
  b) Change the gnulib-tool entry-point script to prefer the shell-based
 implementation if the host OS, as viewed from Python, is native
 Windows (not Cygwin).
  c) Port gnulib-tool.py to native Windows.
  Your choice.

Bruno






OSError: [WinError 193] %1 is not a valid Win32 application

2024-04-30 Thread Jianshan Jiang
Hello,
 I use the newest version of gnulib from git. when I run the
./autogen.sh where I create for sed-4.9. gnulib-tool will throw an
exception like below:

  top/README-release
  top/maint.mk
Traceback (most recent call last):
  File "E:\Githubs\msvc-pkgs\pkgs\gnulib\.gnulib-tool.py", line 30, in

main.main_with_exception_handling()
  File "E:\Githubs\msvc-pkgs\pkgs\gnulib\pygnulib\main.py", line 1367, in
main_with_exception_handling
main()
  File "E:\Githubs\msvc-pkgs\pkgs\gnulib\pygnulib\main.py", line 953, in
main
importer.execute(filetable, transformers)
  File "E:\Githubs\msvc-pkgs\pkgs\gnulib\pygnulib\GLImport.py", line 1222,
in execute
emit = sp.run([joinpath(DIRS['root'], 'build-aux/prefix-gnulib-mk'),
'--from-gnulib-tool',

 
^^^
  File "C:\Python312\Lib\subprocess.py", line 548, in run
with Popen(*popenargs, **kwargs) as process:
 ^^^
  File "C:\Python312\Lib\subprocess.py", line 1026, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
  File "C:\Python312\Lib\subprocess.py", line 1538, in _execute_child
hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
   ^^^
OSError: [WinError 193] %1 is not a valid Win32 application

Finally, I have found the solution. I have add the 'shell=True' into
function sp.run in GLImport.py. You can see the detail
in 001-gnulib-fix-WinError-193.diff.
#!/bin/sh
# Convenience script for regenerating all autogeneratable files that are
# omitted from the version control repository. In particular, this script
# also regenerates all aclocal.m4, config.h.in, Makefile.in, configure files
# with new versions of autoconf or automake.
#
# This script requires autoconf-2.64..2.71 and automake-1.13..1.16 in the PATH.

# Copyright (C) 2003-2023 Free Software Foundation, Inc.
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see .

# Prerequisite (if not used from a released tarball): either
#   - the GNULIB_SRCDIR environment variable pointing to a gnulib checkout, or
#   - a preceding invocation of './autopull.sh'.
#
# Usage: ./autogen.sh [--skip-gnulib]
#
# Options:
#   --skip-gnulib   Avoid fetching files from Gnulib.
#   This option is useful
#   - when you are working from a released tarball (possibly
# with modifications), or
#   - as a speedup, if the set of gnulib modules did not
# change since the last time you ran this script.

# Nuisances.
(unset CDPATH) >/dev/null 2>&1 && unset CDPATH

skip_gnulib=false
skip_gnulib_option=

while :; do
  case "$1" in
--skip-gnulib) skip_gnulib=true; skip_gnulib_option='--skip-gnulib'; shift;;
*) break ;;
  esac
done

# The tests in gettext-tools/tests are not meant to be executable, because
# they have a TESTS_ENVIRONMENT that specifies the shell explicitly.

if ! $skip_gnulib; then
  if test -n "$GNULIB_SRCDIR"; then
test -d "$GNULIB_SRCDIR" || {
  echo "*** GNULIB_SRCDIR is set but does not point to an existing directory." 1>&2
  exit 1
}
  else
GNULIB_SRCDIR=`dirname $(pwd)`/gnulib
test -d "$GNULIB_SRCDIR" || {
  echo "*** Subdirectory 'gnulib' does not yet exist. Use './gitsub.sh pull' to create it, or set the environment variable GNULIB_SRCDIR." 1>&2
  exit 1
}
  fi
  # Now it should contain a gnulib-tool.
  GNULIB_TOOL="$GNULIB_SRCDIR/gnulib-tool"
  test -f "$GNULIB_TOOL" || {
echo "*** gnulib-tool not found." 1>&2
exit 1
  }

  # https://www.gnu.org/software/gnulib/MODULES.html
  GNULIB_MODULES_POSIX_SUPPORT='
acl
alloca
binary-io
btowc
c-ctype
closeout
dfa
eloop-threshold
extensions
fwriting
getdelim
gettext-h
git-version-gen
gitlog-to-changelog
idx
ignore-value
localcharset
manywarnings
mbrlen
mbrtowc
mbsinit
memchr
memrchr
minmax
mkostemp
obstack
perl
progname
readlink
readme-release
regex
rename
selinux-h
ssize_t
stat-macros
stdalign
stdbool
strerror
strverscmp
unlocked-io
update-copyright
verify
version-etc-fsf
wcrtomb
wctob
xalloc
  '
  # Enhancements for POSIX:2008 functions
  

*printf: Don't invoke gl_PRINTF_DIRECTIVE_N when it's not needed

2024-04-30 Thread Bruno Haible
The configure test
  checking whether printf supports the 'n' directive...
leads to some interactive behaviour not only on Windows, but also on Ubuntu,
depending on the contents of $HOME/.config/apport/settings.

Since 2024-02-21, the result of this configure test is not needed any more
in most situations. Therefore, it's a good optimization to not even the
perform the test if it's not needed.


2024-04-30  Bruno Haible  

*printf: Don't invoke gl_PRINTF_DIRECTIVE_N when it's not needed.
* m4/dprintf-posix.m4 (gl_FUNC_DPRINTF_IS_POSIX): Don't require
gl_PRINTF_DIRECTIVE_N if gl_PRINTF_SUPPORT_N_DIRECTIVE is not defined.
* m4/fprintf-posix.m4 (gl_FUNC_FPRINTF_IS_POSIX): Likewise.
* m4/snprintf-posix.m4 (gl_FUNC_SNPRINTF_IS_POSIX): Likewise.
* m4/sprintf-posix.m4 (gl_FUNC_SPRINTF_IS_POSIX): Likewise.
* m4/vasnprintf-posix.m4 (gl_FUNC_VASNPRINTF_IS_POSIX): Likewise.
* m4/vasprintf-posix.m4 (gl_FUNC_VASPRINTF_IS_POSIX): Likewise.
* m4/vdprintf-posix.m4 (gl_FUNC_VDPRINTF_IS_POSIX): Likewise.
* m4/vfprintf-posix.m4 (gl_FUNC_VFPRINTF_IS_POSIX): Likewise.
* m4/vsnprintf-posix.m4 (gl_FUNC_VSNPRINTF_IS_POSIX): Likewise.
* m4/vsprintf-posix.m4 (gl_FUNC_VSPRINTF_IS_POSIX): Likewise.
* m4/obstack-printf-posix.m4 (gl_FUNC_OBSTACK_PRINTF_IS_POSIX): 
Likewise.

diff --git a/m4/dprintf-posix.m4 b/m4/dprintf-posix.m4
index ea9a5f516b..8f74f5a578 100644
--- a/m4/dprintf-posix.m4
+++ b/m4/dprintf-posix.m4
@@ -1,5 +1,5 @@
 # dprintf-posix.m4
-# serial 9
+# serial 10
 dnl Copyright (C) 2007-2024 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -27,7 +27,7 @@ AC_DEFUN([gl_FUNC_DPRINTF_IS_POSIX]
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_A])
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_B])
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_F])
-  AC_REQUIRE([gl_PRINTF_DIRECTIVE_N])
+  
m4_ifdef([gl_PRINTF_SUPPORT_N_DIRECTIVE],[AC_REQUIRE([gl_PRINTF_DIRECTIVE_N])])
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_LS])
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_LC])
   AC_REQUIRE([gl_PRINTF_POSITIONS])
diff --git a/m4/fprintf-posix.m4 b/m4/fprintf-posix.m4
index bf8e0554bd..1d21d806c4 100644
--- a/m4/fprintf-posix.m4
+++ b/m4/fprintf-posix.m4
@@ -1,5 +1,5 @@
 # fprintf-posix.m4
-# serial 20
+# serial 21
 dnl Copyright (C) 2007-2024 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -27,7 +27,7 @@ AC_DEFUN([gl_FUNC_FPRINTF_IS_POSIX]
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_A])
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_B])
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_F])
-  AC_REQUIRE([gl_PRINTF_DIRECTIVE_N])
+  
m4_ifdef([gl_PRINTF_SUPPORT_N_DIRECTIVE],[AC_REQUIRE([gl_PRINTF_DIRECTIVE_N])])
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_LS])
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_LC])
   AC_REQUIRE([gl_PRINTF_POSITIONS])
diff --git a/m4/obstack-printf-posix.m4 b/m4/obstack-printf-posix.m4
index 9f5b00d370..2de42a61ac 100644
--- a/m4/obstack-printf-posix.m4
+++ b/m4/obstack-printf-posix.m4
@@ -1,5 +1,5 @@
 # obstack-printf-posix.m4
-# serial 10
+# serial 11
 dnl Copyright (C) 2008-2024 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -31,7 +31,7 @@ AC_DEFUN([gl_FUNC_OBSTACK_PRINTF_IS_POSIX]
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_A])
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_B])
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_F])
-  AC_REQUIRE([gl_PRINTF_DIRECTIVE_N])
+  
m4_ifdef([gl_PRINTF_SUPPORT_N_DIRECTIVE],[AC_REQUIRE([gl_PRINTF_DIRECTIVE_N])])
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_LS])
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_LC])
   AC_REQUIRE([gl_PRINTF_POSITIONS])
diff --git a/m4/snprintf-posix.m4 b/m4/snprintf-posix.m4
index 5df7b8d835..10d1e5d355 100644
--- a/m4/snprintf-posix.m4
+++ b/m4/snprintf-posix.m4
@@ -1,5 +1,5 @@
 # snprintf-posix.m4
-# serial 21
+# serial 22
 dnl Copyright (C) 2007-2024 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -27,7 +27,7 @@ AC_DEFUN([gl_FUNC_SNPRINTF_IS_POSIX]
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_A])
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_B])
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_F])
-  AC_REQUIRE([gl_PRINTF_DIRECTIVE_N])
+  
m4_ifdef([gl_PRINTF_SUPPORT_N_DIRECTIVE],[AC_REQUIRE([gl_PRINTF_DIRECTIVE_N])])
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_LS])
   AC_REQUIRE([gl_PRINTF_DIRECTIVE_LC])
   AC_REQUIRE([gl_PRINTF_POSITIONS])
diff --git a/m4/sprintf-posix.m4 b/m4/sprintf-posix.m4
index 3cbab1e599..0f5db45ff1 100644
--- a/m4/sprintf-posix.m4
+++ b/m4/sprintf-posix.m4
@@ -1,5 +1,5 @@
 # sprintf-posix.m4
-# serial 18
+# serial 19
 dnl Copyright (C) 2007-2024 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or 

Re: ./configure with MSVC + Debug blocks with dialog box (fixed with patch!)

2024-04-30 Thread Paul Harris
Thanks Bruno!

On Tue, 30 Apr 2024, 7:19 pm Bruno Haible,  wrote:

> [CCing bug-gnulib]
>
> Hi,
>
> Paul Harris wrote:
> > During ./configure, the "intl" configure step tests this condition:
> > checking whether printf supports the 'n' directive...
> >
> > This fails on MSVC, which is fine on Release builds.
> >
> > However, in Debug builds, a GUI Dialog box pops up telling the user about
> > an assert failure, and would the user like to Abort,Retry,Ignore.
> >
> > This blocks the configuration until the user manually presses a button.
> >
> > In gettext-runtime/intl/configure (in the tarball release),
> > line 29702 has a call to _set_invalid_parameter_handler()
> > This almost does the job, but not quite.
> > adding the line: _CrtSetReportMode(_CRT_ASSERT, 0);
> > changes the behaviour to fail without the dialog box.
> >
> > There are other places in the tarball where
> > _set_invalid_parameter_handler() is called, and this line could be added
> in
> > all of those places to be sure, but my tests show it is enough to add it
> to
> > just this one place,
> >
> > here is a patch:
> >
> > diff -ru gettext-runtime/intl/configure gettext-runtime/intl/configure
> > --- gettext-runtime/intl/configure 2023-06-17 19:53:51.0 +0800
> > +++ gettext-runtime/intl/configure 2024-04-29 10:52:53.723390500 +0800
> > @@ -29700,6 +29700,7 @@
> >int count = -1;
> >  #ifdef _MSC_VER
> >_set_invalid_parameter_handler (invalid_parameter_handler);
> > +  _CrtSetReportMode(_CRT_ASSERT, 0);
> >  #endif
> >/* Copy the format string.  Some systems (glibc with
> _FORTIFY_SOURCE=2)
> >   support %n in format strings in read-only memory but not in
> writable
> >
> >
> > These files appear to be generated for the benefit of the tarball, and
> > aren't found in the git at all, so I wasn't sure how to patch anywhere
> else.
> > Perhaps this belongs in m4 or coreutils or autoconf ?  I'm not sure.
>
> Thanks for the report and suggestion. The code comes from Gnulib; therefore
> I'm fixing it in Gnulib.
>
> The use of _CrtSetReportMode requires a #include , says the
> Microsoft
> documentation. Therefore I'm adding that too. (Older mingw versions don't
> have
> , but since we need the workaround only for MSVC, not for mingw,
> this is not a problem.)
>
>
> 2024-04-30  Bruno Haible  
>
> *printf: Avoid a dialog during 'configure' with MSVC in debug mode.
> Suggested by Paul Harris  in
> <
> https://lists.gnu.org/archive/html/bug-gettext/2024-04/msg5.html>.
> * m4/printf.m4 (gl_PRINTF_DIRECTIVE_N): In the test program,
> include
>  and disable the MSVC reporting for assertion failures.
>
> diff --git a/m4/printf.m4 b/m4/printf.m4
> index 0cb14d6f00..220f37cb5e 100644
> --- a/m4/printf.m4
> +++ b/m4/printf.m4
> @@ -1,5 +1,5 @@
>  # printf.m4
> -# serial 91
> +# serial 92
>  dnl Copyright (C) 2003, 2007-2024 Free Software Foundation, Inc.
>  dnl This file is free software; the Free Software Foundation
>  dnl gives unlimited permission to copy and/or distribute it,
> @@ -896,6 +896,7 @@ AC_DEFUN([gl_PRINTF_DIRECTIVE_N]
>  #include 
>  #include 
>  #ifdef _MSC_VER
> +#include 
>  #include 
>  /* See page about "Parameter Validation" on msdn.microsoft.com.
> <
> https://docs.microsoft.com/en-us/cpp/c-runtime-library/parameter-validation
> >
> @@ -922,6 +923,9 @@ AC_DEFUN([gl_PRINTF_DIRECTIVE_N]
>int count = -1;
>  #ifdef _MSC_VER
>_set_invalid_parameter_handler (invalid_parameter_handler);
> +  /* Also avoid an Abort/Retry/Ignore dialog in debug builds.
> + <
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/crtsetreportmode>
> */
> +  _CrtSetReportMode (_CRT_ASSERT, 0);
>  #endif
>signal (SIGABRT, abort_handler);
>/* Copy the format string.  Some systems (glibc with _FORTIFY_SOURCE=2)
>
>
>
>


Re: ./configure with MSVC + Debug blocks with dialog box (fixed with patch!)

2024-04-30 Thread Bruno Haible
[CCing bug-gnulib]

Hi,

Paul Harris wrote:
> During ./configure, the "intl" configure step tests this condition:
> checking whether printf supports the 'n' directive...
> 
> This fails on MSVC, which is fine on Release builds.
> 
> However, in Debug builds, a GUI Dialog box pops up telling the user about
> an assert failure, and would the user like to Abort,Retry,Ignore.
> 
> This blocks the configuration until the user manually presses a button.
> 
> In gettext-runtime/intl/configure (in the tarball release),
> line 29702 has a call to _set_invalid_parameter_handler()
> This almost does the job, but not quite.
> adding the line: _CrtSetReportMode(_CRT_ASSERT, 0);
> changes the behaviour to fail without the dialog box.
> 
> There are other places in the tarball where
> _set_invalid_parameter_handler() is called, and this line could be added in
> all of those places to be sure, but my tests show it is enough to add it to
> just this one place,
> 
> here is a patch:
> 
> diff -ru gettext-runtime/intl/configure gettext-runtime/intl/configure
> --- gettext-runtime/intl/configure 2023-06-17 19:53:51.0 +0800
> +++ gettext-runtime/intl/configure 2024-04-29 10:52:53.723390500 +0800
> @@ -29700,6 +29700,7 @@
>int count = -1;
>  #ifdef _MSC_VER
>_set_invalid_parameter_handler (invalid_parameter_handler);
> +  _CrtSetReportMode(_CRT_ASSERT, 0);
>  #endif
>/* Copy the format string.  Some systems (glibc with _FORTIFY_SOURCE=2)
>   support %n in format strings in read-only memory but not in writable
> 
> 
> These files appear to be generated for the benefit of the tarball, and
> aren't found in the git at all, so I wasn't sure how to patch anywhere else.
> Perhaps this belongs in m4 or coreutils or autoconf ?  I'm not sure.

Thanks for the report and suggestion. The code comes from Gnulib; therefore
I'm fixing it in Gnulib.

The use of _CrtSetReportMode requires a #include , says the Microsoft
documentation. Therefore I'm adding that too. (Older mingw versions don't have
, but since we need the workaround only for MSVC, not for mingw,
this is not a problem.)


2024-04-30  Bruno Haible  

*printf: Avoid a dialog during 'configure' with MSVC in debug mode.
Suggested by Paul Harris  in
.
* m4/printf.m4 (gl_PRINTF_DIRECTIVE_N): In the test program, include
 and disable the MSVC reporting for assertion failures.

diff --git a/m4/printf.m4 b/m4/printf.m4
index 0cb14d6f00..220f37cb5e 100644
--- a/m4/printf.m4
+++ b/m4/printf.m4
@@ -1,5 +1,5 @@
 # printf.m4
-# serial 91
+# serial 92
 dnl Copyright (C) 2003, 2007-2024 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -896,6 +896,7 @@ AC_DEFUN([gl_PRINTF_DIRECTIVE_N]
 #include 
 #include 
 #ifdef _MSC_VER
+#include 
 #include 
 /* See page about "Parameter Validation" on msdn.microsoft.com.


@@ -922,6 +923,9 @@ AC_DEFUN([gl_PRINTF_DIRECTIVE_N]
   int count = -1;
 #ifdef _MSC_VER
   _set_invalid_parameter_handler (invalid_parameter_handler);
+  /* Also avoid an Abort/Retry/Ignore dialog in debug builds.
+ 

  */
+  _CrtSetReportMode (_CRT_ASSERT, 0);
 #endif
   signal (SIGABRT, abort_handler);
   /* Copy the format string.  Some systems (glibc with _FORTIFY_SOURCE=2)






Re: gnulib-tool.py: Emit libtests in testdirs generated Makefile.am.

2024-04-30 Thread Collin Funk
Hi Bruno,

On 4/30/24 12:44 AM, Bruno Haible wrote:
> Yes, it's a good sign, and most probably a consequence of the testing
> with various packages [1][2] that we did.

And the test suite that you wrote. Many thanks for working on that for
me.

Also, thanks for testing all the projects who use cvs. I never learned
how to use it haha.

Collin



gnulib-tool.py: Remove remaining unused instance variables.

2024-04-30 Thread Collin Funk
I pushed the attached patch. It should have removed all the remaining
unused instance variables. -3 GLConfig's to worry about.

CollinFrom 134f6b8a1806b1bcf0d1cd96ffe97e0d249d4581 Mon Sep 17 00:00:00 2001
From: Collin Funk 
Date: Tue, 30 Apr 2024 01:09:55 -0700
Subject: [PATCH] gnulib-tool.py: Remove remaining unused instance variables.

* pygnulib/GLModuleSystem.py (GLModule.__init__)
(GLModuleTable.__init__): Remove the unused GLFileSystem variable. These
classes perform lookups with a GLModuleSystem.
* pygnulib/GLTestDir.py (GLTestDir.__init__): Remove the unused
GLFileAssistant variable. The transformations it performs are not needed
in testdirs.
---
 ChangeLog  | 10 ++
 pygnulib/GLModuleSystem.py |  4 
 pygnulib/GLTestDir.py  |  2 --
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index bd5bb93c0b..5cd01d60d0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2024-04-30  Collin Funk  
+
+	gnulib-tool.py: Remove remaining unused instance variables.
+	* pygnulib/GLModuleSystem.py (GLModule.__init__)
+	(GLModuleTable.__init__): Remove the unused GLFileSystem variable. These
+	classes perform lookups with a GLModuleSystem.
+	* pygnulib/GLTestDir.py (GLTestDir.__init__): Remove the unused
+	GLFileAssistant variable. The transformations it performs are not needed
+	in testdirs.
+
 2024-04-29  Collin Funk  
 
 	gnulib-tool.py: Add type hints to classes.
diff --git a/pygnulib/GLModuleSystem.py b/pygnulib/GLModuleSystem.py
index a5afb5af6f..01ee393d12 100644
--- a/pygnulib/GLModuleSystem.py
+++ b/pygnulib/GLModuleSystem.py
@@ -175,7 +175,6 @@ class GLModule:
 path: str
 patched: bool
 config: GLConfig
-filesystem: GLFileSystem
 modulesystem: GLModuleSystem
 sections: dict[str, str]
 
@@ -202,7 +201,6 @@ def __init__(self, config: GLConfig, name: str, path: str, patched: bool = False
 self.path = path
 self.patched = patched
 self.config = config
-self.filesystem = GLFileSystem(self.config)
 self.modulesystem = GLModuleSystem(self.config)
 # Read the module description file into memory.
 with open(path, mode='r', newline='\n', encoding='utf-8') as file:
@@ -706,7 +704,6 @@ class GLModuleTable:
 tests_modules: list[GLModule]
 final_modules: list[GLModule]
 config: GLConfig
-filesystem: GLFileSystem
 modulesystem: GLModuleSystem
 inc_all_direct_tests: bool
 inc_all_indirect_tests: bool
@@ -750,7 +747,6 @@ def __init__(self, config: GLConfig, inc_all_direct_tests: bool, inc_all_indirec
 raise TypeError('config must be a GLConfig, not %s'
 % type(config).__name__)
 self.config = config
-self.filesystem = GLFileSystem(self.config)
 self.modulesystem = GLModuleSystem(self.config)
 if type(inc_all_direct_tests) is not bool:
 raise TypeError('inc_all_direct_tests must be a bool, not %s'
diff --git a/pygnulib/GLTestDir.py b/pygnulib/GLTestDir.py
index 688224cdce..8ddc1ea4c8 100644
--- a/pygnulib/GLTestDir.py
+++ b/pygnulib/GLTestDir.py
@@ -96,7 +96,6 @@ class GLTestDir:
 emitter: GLEmiter
 filesystem: GLFileSystem
 modulesystem: GLModuleSystem
-assistant: GLFileAssistant
 makefiletable: GLMakefileTable
 
 def __init__(self, config: GLConfig, testdir: str) -> None:
@@ -117,7 +116,6 @@ def __init__(self, config: GLConfig, testdir: str) -> None:
 self.emitter = GLEmiter(self.config)
 self.filesystem = GLFileSystem(self.config)
 self.modulesystem = GLModuleSystem(self.config)
-self.assistant = GLFileAssistant(self.config)
 self.makefiletable = GLMakefileTable(self.config)
 
 # Subdirectory names.
-- 
2.44.0



Re: gnulib-tool.py: Emit libtests in testdirs generated Makefile.am.

2024-04-30 Thread Bruno Haible
Collin Funk wrote:
> Hopefully no other bug reports for gnulib-tool.py since the info-gnu
> announcement other than the one I just patched is a good sign? :)

Yes, it's a good sign, and most probably a consequence of the testing
with various packages [1][2] that we did.

Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00101.html
[2] https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00171.html