date:20240511

This is needed for diffutils, which doesn’t define HAVE_CONFIG_H.
There needs to be some way for a test shared with glibc to discover
whether it should use the Gnulib or the glibc testing framework,
and I guess this is it.
* modules/stdbit-tests (GNULIB_TEST_STDBIT): Define.
* tests/tst-stdbit.h: Use GNULIB_TEST_STDBIT, not HAVE_CONFIG_H.
---
 ChangeLog| 10 ++
 modules/stdbit-tests |  2 ++
 tests/tst-stdbit.h   |  6 +++---
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 6154ef2bc8..3e5df0d22d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2024-05-11  Paul Eggert  
+
+   stdbit: don’t assume -DHAVE_CONFIG_H
+   This is needed for diffutils, which doesn’t define HAVE_CONFIG_H.
+   There needs to be some way for a test shared with glibc to discover
+   whether it should use the Gnulib or the glibc testing framework,
+   and I guess this is it.
+   * modules/stdbit-tests (GNULIB_TEST_STDBIT): Define.
+   * tests/tst-stdbit.h: Use GNULIB_TEST_STDBIT, not HAVE_CONFIG_H.
+
 2024-05-11  Collin Funk  
 
gnulib-tool.py: Filter out dependencies that cannot be found.
diff --git a/modules/stdbit-tests b/modules/stdbit-tests
index 4ef358aca9..a5832c84f2 100644
--- a/modules/stdbit-tests
+++ b/modules/stdbit-tests
@@ -23,6 +23,8 @@ libc-config
 stdint
 
 configure.ac:
+AC_DEFINE([GNULIB_TEST_STDBIT], [1],
+  [Define to 1 so that stdbit tests use the Gnulib framework, not glibc's.])
 
 Makefile.am:
 TESTS += \
diff --git a/tests/tst-stdbit.h b/tests/tst-stdbit.h
index b40d7447bf..0a0ab6b66c 100644
--- a/tests/tst-stdbit.h
+++ b/tests/tst-stdbit.h
@@ -19,14 +19,14 @@
 #ifndef _TST_STDBIT_H
 #define _TST_STDBIT_H
 
-#if HAVE_CONFIG_H
+#if GNULIB_TEST_STDBIT
 # include 
 #endif
 
 #include 
 #include 
 
-#if !HAVE_CONFIG_H
+#if !GNULIB_TEST_STDBIT
 # include 
 # include 
 #else
@@ -46,7 +46,7 @@ struct stdbit_test
   uint64_t res_8, res_16, res_32, res_64;
 };
 
-#if !HAVE_CONFIG_H
+#if !GNULIB_TEST_STDBIT
 # define TEST_TYPE(EXPR, TYPE) \
   _Static_assert (_Generic ((EXPR), TYPE: 1, default: 0), "bad type")
 #elif ((defined __GNUC__ && 2 <= __GNUC__) \
-- 
2.40.1

Re: gnulib-tool (Python) bug: "module count-one-bits doesn't exist"

On 5/11/24 12:26 PM, Paul Eggert wrote:
> To reproduce it in a Gnulib repository, run these commands:
> 
> git checkout 4de6323d5d20996e51097a90f617cd4404a23eba
> ./gnulib-tool --create-testdir --dir foo -h stdbit
> 
> The failing output is as follows. I get this output on Fedora 40 x86-64.
> 
> gnulib-tool: warning: module count-leading-zeros doesn't exist
> gnulib-tool: warning: module count-trailing-zeros doesn't exist
> gnulib-tool: warning: module count-one-bits doesn't exist
> Traceback (most recent call last):
>   File "/home/eggert/src/gnu/gnulib/./.gnulib-tool.py", line 30, in 
> main.main_with_exception_handling()
>   File "/home/eggert/src/gnu/gnulib/pygnulib/main.py", line 1371, in

I've applied the attached patch to fix this crash. Since
Glmodulesystem.find() prints a warning/error message upon looking up a
non-existent module returning, returning None here and crashing is
incorrect.

With the module description from that patch and this gnulib-tool fix:


$ gnulib-tool --create-testdir --dir foo -h stdbit
gnulib-tool: warning: module count-leading-zeros doesn't exist
gnulib-tool: warning: module count-trailing-zerosdoesn't exist
gnulib-tool: warning: module count-one-bits  doesn't exist
Module list with included dependencies (indented):
absolute-header
alignasof
alignasof-tests


And just to confirm that the issue you were running into was due to
the tabs, I added quotes around the module name:


$ gnulib-tool --create-testdir --dir foo -h stdbit
gnulib-tool: warning: module 'count-leading-zeros   ' doesn't exist
gnulib-tool: warning: module 'count-trailing-zeros  ' doesn't exist
gnulib-tool: warning: module 'count-one-bits' doesn't exist
Module list with included dependencies (indented):
absolute-header
alignasof
alignasof-tests
assert-h


I'm not sure why gnulib-tool.sh handles the tabs correctly to be
honest...

CollinFrom 6c3614c1f3147e85ffcdf12bb9510f55064159c2 Mon Sep 17 00:00:00 2001
From: Collin Funk 
Date: Sat, 11 May 2024 21:45:12 -0700
Subject: [PATCH] gnulib-tool.py: Filter out dependencies that cannot be found.

Reported by Paul Eggert in
.

* pygnulib/GLModuleSystem.py (GLModule.getDependenciesWithConditions):
Reorder conditionals to avoid duplicate checks. Filter out None from the
gathered dependencies when gathering module dependencies. Let
GLModuleSystem.find() warn instead of crashing.
---
 ChangeLog  | 10 ++
 pygnulib/GLModuleSystem.py | 15 ---
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index a159f518dc..6154ef2bc8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2024-05-11  Collin Funk  
+
+	gnulib-tool.py: Filter out dependencies that cannot be found.
+	Reported by Paul Eggert in
+	.
+	* pygnulib/GLModuleSystem.py (GLModule.getDependenciesWithConditions):
+	Reorder conditionals to avoid duplicate checks. Filter out None from the
+	gathered dependencies when gathering module dependencies. Let
+	GLModuleSystem.find() warn instead of crashing.
+
 2024-05-11  Collin Funk  
 
 	execinfo: Add tests.
diff --git a/pygnulib/GLModuleSystem.py b/pygnulib/GLModuleSystem.py
index b25779d62e..872961ba91 100644
--- a/pygnulib/GLModuleSystem.py
+++ b/pygnulib/GLModuleSystem.py
@@ -538,17 +538,18 @@ def getDependenciesWithConditions(self) -> list[tuple[GLModule, str | None]]:
 result = []
 for line in lines:
 match = pattern.search(line)
-if match:
-module = line[0 : match.start()]
+if not match:
+module_name = line
+condition = None
+else:
+module_name = line[0 : match.start()]
 condition = line[match.end() :]
 condition = subend(']', '', condition)
-else:
-module = line
-condition = None
-if module != '':
 if condition == 'true':
 condition = None
-result.append(tuple([self.modulesystem.find(module), condition]))
+module = self.modulesystem.find(module_name)
+if module is not None:
+result.append((module, condition))
 self.cache['dependenciesWithCond'] = result
 return self.cache['dependenciesWithCond']
 
-- 
2.45.0

execinfo: Add tests.

I've pushed a basic test for execinfo. Since BSD needs to link to
-lexecinfo unlike glibc. Should catch any bugs that occur there or if
another system adds it as a library.

CollinFrom 06ff525438b5df5c83664535908c02ae398f6e3f Mon Sep 17 00:00:00 2001
From: Collin Funk 
Date: Sat, 11 May 2024 20:46:12 -0700
Subject: [PATCH] execinfo: Add tests.

* modules/execinfo-tests: New file.
* tests/test-execinfo.c (test_backtrace): New function. Simply test that
the symbols defined in execinfo.h can be used.
(main): Use it.
---
 ChangeLog  |  8 +++
 modules/execinfo-tests | 12 ++
 tests/test-execinfo.c  | 54 ++
 3 files changed, 74 insertions(+)
 create mode 100644 modules/execinfo-tests
 create mode 100644 tests/test-execinfo.c

diff --git a/ChangeLog b/ChangeLog
index 9ccd92700e..a159f518dc 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2024-05-11  Collin Funk  
+
+	execinfo: Add tests.
+	* modules/execinfo-tests: New file.
+	* tests/test-execinfo.c (test_backtrace): New function. Simply test that
+	the symbols defined in execinfo.h can be used.
+	(main): Use it.
+
 2024-05-11  Bruno Haible  
 
 	Continue to use spaces for indentation, not tabs.
diff --git a/modules/execinfo-tests b/modules/execinfo-tests
new file mode 100644
index 00..191345cd5c
--- /dev/null
+++ b/modules/execinfo-tests
@@ -0,0 +1,12 @@
+Files:
+tests/test-execinfo.c
+tests/macros.h
+
+Depends-on:
+
+configure.ac:
+
+Makefile.am:
+TESTS += test-execinfo
+check_PROGRAMS += test-execinfo
+test_execinfo_LDADD = $(LDADD) $(LIB_EXECINFO)
diff --git a/tests/test-execinfo.c b/tests/test-execinfo.c
new file mode 100644
index 00..af457c468f
--- /dev/null
+++ b/tests/test-execinfo.c
@@ -0,0 +1,54 @@
+/* Test that execinfo.h defines stub functions.
+   Copyright (C) 2024 Free Software Foundation, Inc.
+
+   This file 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 file 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 .  */
+
+/* Written by Collin Funk , 2024.  */
+
+#include 
+
+/* Specification.  */
+#include 
+
+#include 
+#include 
+
+#include "macros.h"
+
+static void
+test_backtrace (void)
+{
+  void *buffer[10];
+  char **symbols;
+  int size;
+
+  size = backtrace (buffer, SIZEOF (buffer));
+  symbols = backtrace_symbols (buffer, size);
+
+  /* Print the backtrace if possible.  */
+  if (0 < size && symbols != NULL)
+{
+  for (int i = 0; i < size; ++i)
+printf ("%s\n", symbols[i]);
+  free (symbols);
+}
+}
+
+int
+main (void)
+{
+  test_backtrace ();
+
+  return 0;
+}
-- 
2.45.0

Re: gnulib-tool (Python) bug: "module count-one-bits doesn't exist"

On 5/11/24 7:16 PM, Bruno Haible wrote:
> Sorry Paul. No. We have been using spaces for indentation and tabulation
> since 2009, and the coding got significantly simplified by that. Tabs are
> still used in ChangeLog, in Makefile.am snippets (because some 'make'
> programs give a syntax error when the lines that define the commands
> for a target don't all start with a tab), and in files which are occasionally
> synced with glibc. Other than that, please use spaces — instead of
> complicating our lives!

Adding the dependency conditions with spaces instead of tabs seems to
make things work. I assume they should be removed anyways since stdbit
should be preferred over count-*.

That function should filter out None though so I will do that in a bit.

Collin

Re: gnulib-tool (Python) bug: "module count-one-bits doesn't exist"

Paul Eggert wrote:
> > Also in Emacs 'whitespace-mode' I noticed the lines that cause issues
> > use tabs instead of spaces. Shouldn't that be disallowed?
> 
> I'd allow tabs there, myself. In Gnulib we don't use leading tabs, but 
> columnar tabs are OK, e.g., in build-aux/gcc-warning.spec.

Sorry Paul. No. We have been using spaces for indentation and tabulation
since 2009, and the coding got significantly simplified by that. Tabs are
still used in ChangeLog, in Makefile.am snippets (because some 'make'
programs give a syntax error when the lines that define the commands
for a target don't all start with a tab), and in files which are occasionally
synced with glibc. Other than that, please use spaces — instead of
complicating our lives!

I'm applying this.


2024-05-11  Bruno Haible  

Continue to use spaces for indentation, not tabs.
* lib/strftime.c: Untabify. Correct indentation.
* tests/test-posix_memalign.c: Untabify.

diff --git a/lib/strftime.c b/lib/strftime.c
index 9b205e4802..834f3a79f4 100644
--- a/lib/strftime.c
+++ b/lib/strftime.c
@@ -143,11 +143,11 @@ extern char *tzname[];
 
 enum pad_style
 {
-  ZERO_PAD,  /* (default) Pad with 0 unless format says otherwise.  */
-  ALWAYS_ZERO_PAD, /* '0' Always pad with 0.  */
-  SIGN_PAD,/* '+' Always output a sign.  */
-  SPACE_PAD,   /* '_' Pad with space.  */
-  NO_PAD   /* '-' Do not pad.  */
+  ZERO_PAD, /* (default) Pad with 0 unless format says otherwise.  */
+  ALWAYS_ZERO_PAD,  /* '0'   Always pad with 0.  */
+  SIGN_PAD, /* '+'   Always output a sign.  */
+  SPACE_PAD,/* '_'   Pad with space.  */
+  NO_PAD/* '-'   Do not pad.  */
 };
 
 #define TM_YEAR_BASE 1900
diff --git a/tests/test-posix_memalign.c b/tests/test-posix_memalign.c
index 803e40c5f5..af71d6d692 100644
--- a/tests/test-posix_memalign.c
+++ b/tests/test-posix_memalign.c
@@ -63,12 +63,12 @@ main (int argc, char *argv[])
 }
 
   if (sizeof (void *) <= 8)
-   {
- ASSERT (posix_memalign (_blocks[i], 8, size) == 0);
- ASSERT (aligned8_blocks[i] != NULL);
- ASSERT (((uintptr_t) aligned8_blocks[i] % 8) == 0);
- memset (aligned8_blocks[i], 'w', size);
-   }
+{
+  ASSERT (posix_memalign (_blocks[i], 8, size) == 0);
+  ASSERT (aligned8_blocks[i] != NULL);
+  ASSERT (((uintptr_t) aligned8_blocks[i] % 8) == 0);
+  memset (aligned8_blocks[i], 'w', size);
+}
 
   ASSERT (posix_memalign (_blocks[i], 16, size) == 0);
   ASSERT (aligned16_blocks[i] != NULL);
@@ -93,7 +93,7 @@ main (int argc, char *argv[])
   if (sizeof (void *) <= 4)
 free (aligned4_blocks[i]);
   if (sizeof (void *) <= 8)
-   free (aligned8_blocks[i]);
+free (aligned8_blocks[i]);
   free (aligned16_blocks[i]);
   free (aligned32_blocks[i]);
   free (aligned64_blocks[i]);

Re: gnulib-tool (Python) bug: "module count-one-bits doesn't exist"


On 2024-05-11 16:47, Collin Funk wrote:

Also in Emacs 'whitespace-mode' I noticed the lines that cause issues
use tabs instead of spaces. Shouldn't that be disallowed?


I'd allow tabs there, myself. In Gnulib we don't use leading tabs, but 
columnar tabs are OK, e.g., in build-aux/gcc-warning.spec.

Re: gnulib-tool (Python) bug: "module count-one-bits doesn't exist"

Hi Paul,

On 5/11/24 12:26 PM, Paul Eggert wrote:
> git checkout 4de6323d5d20996e51097a90f617cd4404a23eba
> ./gnulib-tool --create-testdir --dir foo -h stdbit

Also in Emacs 'whitespace-mode' I noticed the lines that cause issues
use tabs instead of spaces. Shouldn't that be disallowed?

In gnulib-tool.sh:

sed_dependencies_without_conditions='s/ *\[.*//'

In gnulib-tool.py:

pattern = re.compile(r' *\[')

Collin

Re: gnulib-tool (Python) bug: "module count-one-bits doesn't exist"

Hi Paul,

On 5/11/24 12:26 PM, Paul Eggert wrote:
> To reproduce it in a Gnulib repository, run these commands:
> 
> git checkout 4de6323d5d20996e51097a90f617cd4404a23eba
> ./gnulib-tool --create-testdir --dir foo -h stdbit
> 
> The failing output is as follows. I get this output on Fedora 40 x86-64.
> 
> gnulib-tool: warning: module count-leading-zeros doesn't exist
> gnulib-tool: warning: module count-trailing-zeros doesn't exist
> gnulib-tool: warning: module count-one-bits doesn't exist

Thanks for the instructions and report. This is because this function
in GLModule:

def getDependenciesWithConditions(self) -> list[tuple[GLModule, str | 
None]]:
# Do stuff
result.append(tuple([self.modulesystem.find(module), condition]))
# Store in cache
return result

So here the return type is wrong, since modulesystem.find() returns
None but prints a warning when the module cannot be found.

So the correct return type is:

   list[tuple[GLModule | None, str | None]]

I'll start working on a patch now to filter out unfound modules
(None). Also that function can be cleaned up a bit now that I look at
it.

Collin

Re: gl_linked_iterator doesn't initialize all fields.

Hi Bruno,

Thanks for the explanations.

On 5/11/24 6:06 AM, Bruno Haible wrote:
>> But my instinct tells me these initializations should be done
>> unconditionally so undefined behavior is avoided.
>
> There is no undefined behaviour here, only a false alarm.

My thinking was that if iterator.count was accessed after using that
function. Since you would be using an unassigned value.

But I now see that is probably an incorrect way to use the interface.
And internally the 'p' and 'q' members are used for iteration.

Collin

error-h: Avoid namespace pollution on mingw

Building GNU m4 on mingw, I get this error:

  CC   eval.o
In file included from ../lib/error.h:28,
 from ../../src/m4.h:46,
 from ../../src/eval.c:27:
../../src/eval.c:50:5: error: expected identifier before numeric constant
   50 | NO_ERROR,
  | ^~~~

The cause is that mingw has an  that is unrelated to glibc's 
and contains many macro definitions that are redundant with .
https://raw.githubusercontent.com/mingw-w64/mingw-w64/master/mingw-w64-headers/include/error.h

This patch fixes the compilation error.


2024-05-11  Bruno Haible  

error-h: Avoid namespace pollution on mingw.
* lib/error.in.h: Don't include mingw's .

diff --git a/lib/error.in.h b/lib/error.in.h
index 51f8cafd10..1ba066a863 100644
--- a/lib/error.in.h
+++ b/lib/error.in.h
@@ -23,7 +23,7 @@
or error_at_line(...) invocations.  */
 
 /* The include_next requires a split double-inclusion guard.  */
-#if @HAVE_ERROR_H@
+#if @HAVE_ERROR_H@ && !defined __MINGW32__
 # @INCLUDE_NEXT@ @NEXT_ERROR_H@
 #endif

Re: doc: Mention backtrace functions supported on BSD.

On 5/11/24 5:34 AM, Bruno Haible wrote:
> In the documentation, if a function was added in a certain OS release, we 
> still
> mention it as missing in the previous OS release, because the goal of the
> documentation is to tell the user what to expect. And it's the user who 
> decides
> whether portability to OpenBSD version 6.9 is relevant for them, not us.
> Also I still have VMs for FreeBSD 5 and OpenBSD 6.x, and if the behaviour
> on these VMs is different than on the newest versions, I want to know why.

Ah, you are right. That was my mistake.

Thanks!

Collin

gnulib-tool (Python) bug: "module count-one-bits doesn't exist"

I ran into a problem when using gnulib-tool on an earlier version of the 
new stdbit module. The problem went away when I had GNULIB_TOOL_IMPL=sh 
in the environment. The gnulib-tool code hasn't changed since the commit 
in question, so the gnulib-tool bug is presumably still there even 
though I've tweaked stdbit not to tickle the bug.


To reproduce it in a Gnulib repository, run these commands:

git checkout 4de6323d5d20996e51097a90f617cd4404a23eba
./gnulib-tool --create-testdir --dir foo -h stdbit

The failing output is as follows. I get this output on Fedora 40 x86-64.

gnulib-tool: warning: module count-leading-zeros doesn't exist
gnulib-tool: warning: module count-trailing-zerosdoesn't exist
gnulib-tool: warning: module count-one-bits  doesn't exist
Traceback (most recent call last):
  File "/home/eggert/src/gnu/gnulib/./.gnulib-tool.py", line 30, in 


main.main_with_exception_handling()
  File "/home/eggert/src/gnu/gnulib/pygnulib/main.py", line 1371, in 
main_with_exception_handling

main(temporary_directory)
  File "/home/eggert/src/gnu/gnulib/pygnulib/main.py", line 1073, in main
testdir.execute()
  File "/home/eggert/src/gnu/gnulib/pygnulib/GLTestDir.py", line 189, 
in execute

modules = moduletable.transitive_closure([requested_module])
  ^^
  File "/home/eggert/src/gnu/gnulib/pygnulib/GLModuleSystem.py", line 
853, in transitive_closure

duplicate_depmodule_names = [ depmodule.name
  ^^
AttributeError: 'NoneType' object has no attribute 'name'

[PATCH 4/4] stdbit: clean up namespace and simplify

Fix namespace pollution in substitute stdbit.h.
Clean up and simplify some of the non-GCC code, by preferring
inline functions to macros and substituting something
more straightforward than a de Bruijn hash (possibly faster?).
The non-GCC non-C23 substitutes should all compile to
branch-free code, if the compiler is good.
* lib/stdbit.c (COUNT_LEADING_ZEROS_INLINE)
(COUNT_TRAILING_ZEROS_INLINE, COUNT_ONE_BITS_INLINE): Remove.
(__gl_stdbit_clztab) [!_GL_STDBIT_HAS_BUILTIN_CLZ && !_MSC_VER]:
New constant array.
(__gl_stdbit_popcount_support): Adjust to stdbit.in.h changes.
* lib/stdbit.in.h: Do not include  or .
Check that bytes are 8 bits.
(COUNT_LEADING_ZEROS_INLINE, COUNT_TRAILING_ZEROS_INLINE)
(COUNT_ONE_BITS_INLINE, COUNT_LEADING_ZEROS)
(count_leading_zeros_32, count_leading_zeros)
(count_leading_zeros_l, count_leading_zeros_ll)
(COUNT_TRAILING_ZEROS, count_trailing_zeros_32)
(count_trailing_zeros, count_trailing_zeros_l)
(count_trailing_zeros_ll, COUNT_ONE_BITS, count_one_bits_32)
(COUNT_ONE_BITS_GENERIC, count_one_bits, count_one_bits_l)
(count_one_bits_ll): Remove, replacing all uses with ...
(_GL_STDBIT_HAS_BUILTIN_CLZ)
(_GL_STDBIT_HAS_BUILTIN_CTZ, _GL_STDBIT_HAS_BUILTIN_POPCOUNT)
(__gl_stdbit_clz, __gl_stdbit_clzl, __gl_stdbit_clzll)
(__gl_stdbit_ctz, __gl_stdbit_ctzl, __gl_stdbit_ctzll)
(__gl_stdbit_popcount, __gl_stdbit_popcountl, __gl_stdbit_popcountll)
(__gl_stdbit_popcount255): ... these new functions and macros.
(__popcnt64): Omit unnecessary casts.
(__gl_stdbit_popcount_support): Rename from popcount_support
and make it a signed char since that’s all we need.
(__gl_stdbit_popcount_supported): Rename from popcount_supported.
All uses changed.
* modules/stdbit (Depends-on): Add assert-h, for static_assert.
---
 ChangeLog   |  36 
 lib/stdbit.c|  50 -
 lib/stdbit.in.h | 553 +++-
 modules/stdbit  |   1 +
 4 files changed, 298 insertions(+), 342 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index b0e7efd02c..b4319fc47b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,41 @@
 2024-05-11  Paul Eggert  
 
+   stdbit: clean up namespace and simplify
+   Fix namespace pollution in substitute stdbit.h.
+   Clean up and simplify some of the non-GCC code, by preferring
+   inline functions to macros and substituting something
+   more straightforward than a de Bruijn hash (possibly faster?).
+   The non-GCC non-C23 substitutes should all compile to
+   branch-free code, if the compiler is good.
+   * lib/stdbit.c (COUNT_LEADING_ZEROS_INLINE)
+   (COUNT_TRAILING_ZEROS_INLINE, COUNT_ONE_BITS_INLINE): Remove.
+   (__gl_stdbit_clztab) [!_GL_STDBIT_HAS_BUILTIN_CLZ && !_MSC_VER]:
+   New constant array.
+   (__gl_stdbit_popcount_support): Adjust to stdbit.in.h changes.
+   * lib/stdbit.in.h: Do not include  or .
+   Check that bytes are 8 bits.
+   (COUNT_LEADING_ZEROS_INLINE, COUNT_TRAILING_ZEROS_INLINE)
+   (COUNT_ONE_BITS_INLINE, COUNT_LEADING_ZEROS)
+   (count_leading_zeros_32, count_leading_zeros)
+   (count_leading_zeros_l, count_leading_zeros_ll)
+   (COUNT_TRAILING_ZEROS, count_trailing_zeros_32)
+   (count_trailing_zeros, count_trailing_zeros_l)
+   (count_trailing_zeros_ll, COUNT_ONE_BITS, count_one_bits_32)
+   (COUNT_ONE_BITS_GENERIC, count_one_bits, count_one_bits_l)
+   (count_one_bits_ll): Remove, replacing all uses with ...
+   (_GL_STDBIT_HAS_BUILTIN_CLZ)
+   (_GL_STDBIT_HAS_BUILTIN_CTZ, _GL_STDBIT_HAS_BUILTIN_POPCOUNT)
+   (__gl_stdbit_clz, __gl_stdbit_clzl, __gl_stdbit_clzll)
+   (__gl_stdbit_ctz, __gl_stdbit_ctzl, __gl_stdbit_ctzll)
+   (__gl_stdbit_popcount, __gl_stdbit_popcountl, __gl_stdbit_popcountll)
+   (__gl_stdbit_popcount255): ... these new functions and macros.
+   (__popcnt64): Omit unnecessary casts.
+   (__gl_stdbit_popcount_support): Rename from popcount_support
+   and make it a signed char since that’s all we need.
+   (__gl_stdbit_popcount_supported): Rename from popcount_supported.
+   All uses changed.
+   * modules/stdbit (Depends-on): Add assert-h, for static_assert.
+
stdbit: remove most module dependence
Remove dependence of stdbit on the modules count-leading-zeros,
count-trailing-zeros, and count-one-bits.  stdbit is part of C23
diff --git a/lib/stdbit.c b/lib/stdbit.c
index 2a5626a902..f2a51b10f7 100644
--- a/lib/stdbit.c
+++ b/lib/stdbit.c
@@ -1,9 +1,51 @@
+/* Support C23 bit and byte utilities on non-C23 platforms.
+
+   Copyright 2024 Free Software Foundation, Inc.
+
+   This file is free software: you can redistribute it and/or modify
+   it under the terms of the GNU Lesser General Public License as
+   published by the Free Software Foundation; either version 2.1 of the
+   License, or (at your option) any later version.
+
+   This file is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the

[PATCH 3/4] stdbit: remove most module dependence

Remove dependence of stdbit on the modules count-leading-zeros,
count-trailing-zeros, and count-one-bits.  stdbit is part of C23
and in the long run is more likely to be more portable, so code
should start preferring it.
* lib/stdbit.c (popcount_support): New var, if needed.
* lib/stdbit.in.h: Contain contents of count-leading-zeros.h,
count-trailing-zeros.h, and count-one-bits.h instead of including
those files.  In the long run those files should be stubs that are
implemented via stdbit.
* modules/stdbit (Depends-on): Do not depend on count-leading-zeros,
count-trailing-zeros, count-one-bits.
---
 ChangeLog   |  13 ++
 lib/stdbit.c|   6 +
 lib/stdbit.in.h | 357 +++-
 modules/stdbit  |   3 -
 4 files changed, 373 insertions(+), 6 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 083babb011..b0e7efd02c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,18 @@
 2024-05-11  Paul Eggert  
 
+   stdbit: remove most module dependence
+   Remove dependence of stdbit on the modules count-leading-zeros,
+   count-trailing-zeros, and count-one-bits.  stdbit is part of C23
+   and in the long run is more likely to be more portable, so code
+   should start preferring it.
+   * lib/stdbit.c (popcount_support): New var, if needed.
+   * lib/stdbit.in.h: Contain contents of count-leading-zeros.h,
+   count-trailing-zeros.h, and count-one-bits.h instead of including
+   those files.  In the long run those files should be stubs that are
+   implemented via stdbit.
+   * modules/stdbit (Depends-on): Do not depend on count-leading-zeros,
+   count-trailing-zeros, count-one-bits.
+
stdbit-tests: new module
* config/srclist.txt: Add files containing stdbit test cases
shared with glibc.
diff --git a/lib/stdbit.c b/lib/stdbit.c
index 0346ec095c..2a5626a902 100644
--- a/lib/stdbit.c
+++ b/lib/stdbit.c
@@ -1,3 +1,9 @@
 #include 
 #define _GL_STDBIT_INLINE _GL_EXTERN_INLINE
+#define COUNT_LEADING_ZEROS_INLINE _GL_EXTERN_INLINE
+#define COUNT_TRAILING_ZEROS_INLINE _GL_EXTERN_INLINE
+#define COUNT_ONE_BITS_INLINE _GL_EXTERN_INLINE
 #include 
+#if 1500 <= _MSC_VER && (defined _M_IX86 || defined _M_X64)
+int popcount_support = -1;
+#endif
diff --git a/lib/stdbit.in.h b/lib/stdbit.in.h
index 3701344498..63be4737a8 100644
--- a/lib/stdbit.in.h
+++ b/lib/stdbit.in.h
@@ -25,9 +25,360 @@
  #error "Please include config.h first."
 #endif
 
-#include 
-#include 
-#include 
+/* Taken from count-leading-zeros.h.  */
+#include 
+#include 
+
+_GL_INLINE_HEADER_BEGIN
+#ifndef COUNT_LEADING_ZEROS_INLINE
+# define COUNT_LEADING_ZEROS_INLINE _GL_INLINE
+#endif
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* Assuming the GCC builtin is BUILTIN and the MSC builtin is MSC_BUILTIN,
+   expand to code that computes the number of leading zeros of the local
+   variable 'x' of type TYPE (an unsigned integer type) and return it
+   from the current function.  */
+#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4) \
+|| (__clang_major__ >= 4)
+# define COUNT_LEADING_ZEROS(BUILTIN, MSC_BUILTIN, TYPE)\
+  return x ? BUILTIN (x) : CHAR_BIT * sizeof x;
+#elif _MSC_VER
+# pragma intrinsic (_BitScanReverse)
+# if defined _M_X64
+#  pragma intrinsic (_BitScanReverse64)
+# endif
+# define COUNT_LEADING_ZEROS(BUILTIN, MSC_BUILTIN, TYPE)\
+do  \
+  { \
+unsigned long result;   \
+if (MSC_BUILTIN (, x))   \
+  return CHAR_BIT * sizeof x - 1 - result;  \
+return CHAR_BIT * sizeof x; \
+  } \
+while (0)
+#else
+# define COUNT_LEADING_ZEROS(BUILTIN, MSC_BUILTIN, TYPE)\
+do  \
+  { \
+int count;  \
+unsigned int leading_32;\
+if (! x)\
+  return CHAR_BIT * sizeof x;   \
+for (count = 0; \
+ (leading_32 = ((x >> (sizeof (TYPE) * CHAR_BIT - 32))  \
+& 0xU), \
+  count < CHAR_BIT * sizeof x - 32 && !leading_32); \
+ count += 32)   \
+  x = x << 31 << 1; \
+return count + count_leading_zeros_32 (leading_32);

[PATCH 2/4] stdbit-tests: new module

* config/srclist.txt: Add files containing stdbit test cases
shared with glibc.
* modules/stdbit-tests: New file.
* tests/support/test-driver.c, tests/tst-stdbit.h:
New files, copied from glibc with changes.
* tests/tst-stdc_bit_ceil.c:
* tests/tst-stdc_bit_floor.c, tests/tst-stdc_bit_width.c:
* tests/tst-stdc_count_ones.c, tests/tst-stdc_count_zeros.c:
* tests/tst-stdc_first_leading_one.c:
* tests/tst-stdc_first_leading_zero.c:
* tests/tst-stdc_first_trailing_one.c:
* tests/tst-stdc_first_trailing_zero.c:
* tests/tst-stdc_has_single_bit.c, tests/tst-stdc_leading_ones.c:
* tests/tst-stdc_leading_zeros.c, tests/tst-stdc_trailing_ones.c:
* tests/tst-stdc_trailing_zeros.c:
New files, copied verbatim from glibc.
---
 ChangeLog|  18 +++
 config/srclist.txt   |  15 ++
 lib/stdbit.in.h  | 115 +++---
 modules/stdbit-tests |  42 +
 tests/support/test-driver.c  |   5 +
 tests/tst-stdbit.h   | 225 +++
 tests/tst-stdc_bit_ceil.c|  88 +++
 tests/tst-stdc_bit_floor.c   |  88 +++
 tests/tst-stdc_bit_width.c   |  88 +++
 tests/tst-stdc_count_ones.c  |  88 +++
 tests/tst-stdc_count_zeros.c |  88 +++
 tests/tst-stdc_first_leading_one.c   |  88 +++
 tests/tst-stdc_first_leading_zero.c  |  88 +++
 tests/tst-stdc_first_trailing_one.c  |  88 +++
 tests/tst-stdc_first_trailing_zero.c |  88 +++
 tests/tst-stdc_has_single_bit.c  |  88 +++
 tests/tst-stdc_leading_ones.c|  88 +++
 tests/tst-stdc_leading_zeros.c   |  88 +++
 tests/tst-stdc_trailing_ones.c   |  88 +++
 tests/tst-stdc_trailing_zeros.c  |  88 +++
 20 files changed, 1592 insertions(+), 60 deletions(-)
 create mode 100644 modules/stdbit-tests
 create mode 100644 tests/support/test-driver.c
 create mode 100644 tests/tst-stdbit.h
 create mode 100644 tests/tst-stdc_bit_ceil.c
 create mode 100644 tests/tst-stdc_bit_floor.c
 create mode 100644 tests/tst-stdc_bit_width.c
 create mode 100644 tests/tst-stdc_count_ones.c
 create mode 100644 tests/tst-stdc_count_zeros.c
 create mode 100644 tests/tst-stdc_first_leading_one.c
 create mode 100644 tests/tst-stdc_first_leading_zero.c
 create mode 100644 tests/tst-stdc_first_trailing_one.c
 create mode 100644 tests/tst-stdc_first_trailing_zero.c
 create mode 100644 tests/tst-stdc_has_single_bit.c
 create mode 100644 tests/tst-stdc_leading_ones.c
 create mode 100644 tests/tst-stdc_leading_zeros.c
 create mode 100644 tests/tst-stdc_trailing_ones.c
 create mode 100644 tests/tst-stdc_trailing_zeros.c

diff --git a/ChangeLog b/ChangeLog
index 1019917f36..083babb011 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,23 @@
 2024-05-11  Paul Eggert  
 
+   stdbit-tests: new module
+   * config/srclist.txt: Add files containing stdbit test cases
+   shared with glibc.
+   * modules/stdbit-tests: New file.
+   * tests/support/test-driver.c, tests/tst-stdbit.h:
+   New files, copied from glibc with changes.
+   * tests/tst-stdc_bit_ceil.c:
+   * tests/tst-stdc_bit_floor.c, tests/tst-stdc_bit_width.c:
+   * tests/tst-stdc_count_ones.c, tests/tst-stdc_count_zeros.c:
+   * tests/tst-stdc_first_leading_one.c:
+   * tests/tst-stdc_first_leading_zero.c:
+   * tests/tst-stdc_first_trailing_one.c:
+   * tests/tst-stdc_first_trailing_zero.c:
+   * tests/tst-stdc_has_single_bit.c, tests/tst-stdc_leading_ones.c:
+   * tests/tst-stdc_leading_zeros.c, tests/tst-stdc_trailing_ones.c:
+   * tests/tst-stdc_trailing_zeros.c:
+   New files, copied verbatim from glibc.
+
stdbit: new module
* doc/gnulib-tool.texi, doc/gnulib.texi: Mention it.
* doc/posix-headers/stdbit.texi, lib/stdbit.c, lib/stdbit.in.h:
diff --git a/config/srclist.txt b/config/srclist.txt
index 78f77aafd2..34ffd63aec 100644
--- a/config/srclist.txt
+++ b/config/srclist.txt
@@ -71,6 +71,21 @@ $LIBCSRC posix/regex.h   lib
 #$LIBCSRC posix/regex_internal.h   lib
 #$LIBCSRC posix/regexec.c  lib
 #$LIBCSRC stdlib/canonicalize   lib/canonicalize-lgpl.c
+#$LIBCSRC stdlib/tst-stdbit.h  tests
+$LIBCSRC stdlib/tst-stdc_bit_ceil.ctests
+$LIBCSRC stdlib/tst-stdc_bit_floor.c   tests
+$LIBCSRC stdlib/tst-stdc_bit_width.c   tests
+$LIBCSRC stdlib/tst-stdc_count_ones.c  tests
+$LIBCSRC stdlib/tst-stdc_count_zeros.c tests
+$LIBCSRC stdlib/tst-stdc_first_leading_one.c   tests
+$LIBCSRC stdlib/tst-stdc_first_leading_zero.c  tests
+$LIBCSRC stdlib/tst-stdc_first_trailing_one.c  tests
+$LIBCSRC stdlib/tst-stdc_first_trailing_zero.c tests
+$LIBCSRC stdlib/tst-stdc_has_single_bit.c  tests
+$LIBCSRC stdlib/tst-stdc_leading_ones.ctests
+$LIBCSRC stdlib/tst-stdc_leading_zeros.c   tests
+$LIBCSRC

[PATCH 1/4] stdbit: new module

* doc/gnulib-tool.texi, doc/gnulib.texi: Mention it.
* doc/posix-headers/stdbit.texi, lib/stdbit.c, lib/stdbit.in.h:
* m4/stdbit_h.m4, modules/stdbit:
New files.
---
 ChangeLog |   8 +
 doc/gnulib-tool.texi  |   1 +
 doc/gnulib.texi   |   2 +
 doc/posix-headers/stdbit.texi |  25 ++
 lib/stdbit.c  |   3 +
 lib/stdbit.in.h   | 640 ++
 m4/stdbit_h.m4|  19 +
 modules/stdbit|  44 +++
 8 files changed, 742 insertions(+)
 create mode 100644 doc/posix-headers/stdbit.texi
 create mode 100644 lib/stdbit.c
 create mode 100644 lib/stdbit.in.h
 create mode 100644 m4/stdbit_h.m4
 create mode 100644 modules/stdbit

diff --git a/ChangeLog b/ChangeLog
index da40ff41de..1019917f36 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2024-05-11  Paul Eggert  
+
+   stdbit: new module
+   * doc/gnulib-tool.texi, doc/gnulib.texi: Mention it.
+   * doc/posix-headers/stdbit.texi, lib/stdbit.c, lib/stdbit.in.h:
+   * m4/stdbit_h.m4, modules/stdbit:
+   New files.
+
 2024-05-11  Bruno Haible  
 
doc: Mention module execinfo.
diff --git a/doc/gnulib-tool.texi b/doc/gnulib-tool.texi
index 9ed30c2055..5a2fd19cac 100644
--- a/doc/gnulib-tool.texi
+++ b/doc/gnulib-tool.texi
@@ -585,6 +585,7 @@ This is true for the following POSIX or ISO C standardized 
header files:
 @item @code{spawn.h}
 @item @code{stdalign.h}
 @item @code{stdarg.h}
+@item @code{stdbit.h}
 @item @code{stddef.h}
 @item @code{stdint.h}
 @item @code{stdio.h}
diff --git a/doc/gnulib.texi b/doc/gnulib.texi
index 55cf6ebcc9..6cbd10619e 100644
--- a/doc/gnulib.texi
+++ b/doc/gnulib.texi
@@ -1082,6 +1082,7 @@ which (known) portability problems are not worked around 
by Gnulib.
 * stdalign.h::
 * stdarg.h::
 * stdatomic.h::
+* stdbit.h::
 * stdbool.h::
 * stdckdint.h::
 * stddef.h::
@@ -1174,6 +1175,7 @@ which (known) portability problems are not worked around 
by Gnulib.
 @include posix-headers/stdalign.texi
 @include posix-headers/stdarg.texi
 @include posix-headers/stdatomic.texi
+@include posix-headers/stdbit.texi
 @include posix-headers/stdbool.texi
 @include posix-headers/stdckdint.texi
 @include posix-headers/stddef.texi
diff --git a/doc/posix-headers/stdbit.texi b/doc/posix-headers/stdbit.texi
new file mode 100644
index 00..8870668a59
--- /dev/null
+++ b/doc/posix-headers/stdbit.texi
@@ -0,0 +1,25 @@
+@node stdbit.h
+@section @file{stdbit.h}
+
+Gnulib module: stdbit
+
+Portability problems fixed by Gnulib:
+@itemize
+@item
+This header file is missing on many non-C23 platforms:
+glibc 2.38, FreeBSD 14.0, NetBSD 10.0, OpenBSD 7.5,
+AIX 7.3, HP-UX 11.31, Solaris 11.4, mingw, MSVC 17, Android 15.
+@end itemize
+
+Portability problems not fixed by Gnulib:
+@itemize
+@item
+On older non-C23 platforms lacking @code{typeof} or equivalent, a call
+to @code{stdc_bit_floor} and @code{stdc_bit_ceil} may yield a type
+that is wider than its argument.  Although C23 seems to allow this,
+it differs from GNU behavior.
+
+@item
+On non-C23 platforms, type-generic functions apply portably only to
+the standard unsigned integer types specified by C17 or earlier.
+@end itemize
diff --git a/lib/stdbit.c b/lib/stdbit.c
new file mode 100644
index 00..0346ec095c
--- /dev/null
+++ b/lib/stdbit.c
@@ -0,0 +1,3 @@
+#include 
+#define _GL_STDBIT_INLINE _GL_EXTERN_INLINE
+#include 
diff --git a/lib/stdbit.in.h b/lib/stdbit.in.h
new file mode 100644
index 00..a2fff04772
--- /dev/null
+++ b/lib/stdbit.in.h
@@ -0,0 +1,640 @@
+/* stdbit.h - C23 bit and byte utilities for non-C23 platforms
+
+   Copyright 2024 Free Software Foundation, Inc.
+
+   This file is free software: you can redistribute it and/or modify
+   it under the terms of the GNU Lesser General Public License as
+   published by the Free Software Foundation; either version 2.1 of the
+   License, or (at your option) any later version.
+
+   This file 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 Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public License
+   along with this program.  If not, see .  */
+
+/* Written by Paul Eggert.  */
+
+#ifndef STDBIT_H
+#define STDBIT_H 1
+
+/* This file uses _GL_INLINE, WORDS_BIGENDIAN.  */
+#if !_GL_CONFIG_H_INCLUDED
+ #error "Please include config.h first."
+#endif
+
+#include 
+#include 
+#include 
+
+/* An expression, preferably with the type of A, that has the value of B.  */
+#if ((defined __GNUC__ && 2 <= __GNUC__) \
+ || (defined __clang_major__ && 4 <= __clang_major__) \
+ || (defined __IBMC__ && 1210 <= __IBMC__ && defined __IBM__TYPEOF__) \
+ || (defined __SUNPRO_C && 0x5110 <= __SUNPRO_C && !__STDC__))
+# define _GL_STDBIT_TYPEOF_CAST(a, b)

[PATCH 0/4] New stdbit module, for C23 style stdbit.h

2024-05-11 Thread Simon Josefsson via Gnulib discussion list

These patches add a new module to support 
on non-C23 platforms that lack it, which is most platforms
these days: it's new in glibc 2.39 (released January)
and other platforms I consulted don't have it yet.

This first implementation takes the simple approach
of assuming that stdbit.h works if it exists, which
is good enough for the platforms I tested it on.
We can complicate later if needed, with include_next etc.

Paul Eggert (4):
  stdbit: new module
  stdbit-tests: new module
  stdbit: remove most module dependence
  stdbit: clean up namespace and simplify

 ChangeLog|  75 +++
 config/srclist.txt   |  15 +
 doc/gnulib-tool.texi |   1 +
 doc/gnulib.texi  |   2 +
 doc/posix-headers/stdbit.texi|  25 +
 lib/stdbit.c |  51 ++
 lib/stdbit.in.h  | 863 +++
 m4/stdbit_h.m4   |  19 +
 modules/stdbit   |  42 ++
 modules/stdbit-tests |  42 ++
 tests/support/test-driver.c  |   5 +
 tests/tst-stdbit.h   | 225 +++
 tests/tst-stdc_bit_ceil.c|  88 +++
 tests/tst-stdc_bit_floor.c   |  88 +++
 tests/tst-stdc_bit_width.c   |  88 +++
 tests/tst-stdc_count_ones.c  |  88 +++
 tests/tst-stdc_count_zeros.c |  88 +++
 tests/tst-stdc_first_leading_one.c   |  88 +++
 tests/tst-stdc_first_leading_zero.c  |  88 +++
 tests/tst-stdc_first_trailing_one.c  |  88 +++
 tests/tst-stdc_first_trailing_zero.c |  88 +++
 tests/tst-stdc_has_single_bit.c  |  88 +++
 tests/tst-stdc_leading_ones.c|  88 +++
 tests/tst-stdc_leading_zeros.c   |  88 +++
 tests/tst-stdc_trailing_ones.c   |  88 +++
 tests/tst-stdc_trailing_zeros.c  |  88 +++
 26 files changed, 2597 insertions(+)
 create mode 100644 doc/posix-headers/stdbit.texi
 create mode 100644 lib/stdbit.c
 create mode 100644 lib/stdbit.in.h
 create mode 100644 m4/stdbit_h.m4
 create mode 100644 modules/stdbit
 create mode 100644 modules/stdbit-tests
 create mode 100644 tests/support/test-driver.c
 create mode 100644 tests/tst-stdbit.h
 create mode 100644 tests/tst-stdc_bit_ceil.c
 create mode 100644 tests/tst-stdc_bit_floor.c
 create mode 100644 tests/tst-stdc_bit_width.c
 create mode 100644 tests/tst-stdc_count_ones.c
 create mode 100644 tests/tst-stdc_count_zeros.c
 create mode 100644 tests/tst-stdc_first_leading_one.c
 create mode 100644 tests/tst-stdc_first_leading_zero.c
 create mode 100644 tests/tst-stdc_first_trailing_one.c
 create mode 100644 tests/tst-stdc_first_trailing_zero.c
 create mode 100644 tests/tst-stdc_has_single_bit.c
 create mode 100644 tests/tst-stdc_leading_ones.c
 create mode 100644 tests/tst-stdc_leading_zeros.c
 create mode 100644 tests/tst-stdc_trailing_ones.c
 create mode 100644 tests/tst-stdc_trailing_zeros.c

--
2.44.0

Re: De-vendoring gnulib in Debian packages

Bruno Haible  writes:

> Simon Josefsson wrote:
>> Finally, while this is somewhat gnulib specific, I think the practice
>> goes beyond gnulib
>
> Yes, gnulib-tool for modules written in C is similar to
>
>   * 'npm install' for JavaScript source code packages [1],
>   * 'cargo fetch' for Rust source code packages [2],
>
> except that gnulib-tool is simpler: it fetches from a single source location
> only.
>
> How does Debian handle these kinds of source-code dependencies?

I don't know the details but I believe those commands are turned into
local requests for source code, either vendored or previously packaged
in Debian.  No network access during builds.  Same for Go packages,
which I have some experience with, although for Go packages they lose
the strict versioning so if Go package X declare a depedency on package
Y version Z then on Debian it may build against version Z+1 or Z+2 which
may in theory break and was not upstream's intended or supported
configuration.  We have a circular dependency situation for some core Go
libraries in Debian right now due to this.

I think fundamentally the shift that causes challenges for distributions
may be dealing with packages dependencies that are version >= X to
package dependencies that are version = X.  If there is a desire to
support that, some new patterns of the work flow is needed.  Some
package maintainers reject this approach and refuse to co-operate with
those upstreams, but I'm not sure if this is a long-term winning
strategy: it often just lead to useful projects not being available
through distributions, and users suffers as a result.

/Simon

signature.asc
Description: PGP signature

Re: De-vendoring gnulib in Debian packages

2024-05-11 Thread Simon Josefsson via Gnulib discussion list


On 2024-05-11 07:09, Simon Josefsson via Gnulib discussion list wrote:

I would assume that (some stripped down
version of) git is a requirement to do any useful work on any platform
these days, so maybe it isn't a problem


Yes, my impression also is that Git has migrated into the realm of 
cc/gcc in that everybody has it, so it can depend indirectly on a 
possibly earlier version of itself.


Although it is worrisome that our collective trusted computing base 
keeps growing, let's face it, if there's a security bug in Git we're all 
in big trouble anyway.

Re: continuous integrations — own runners

Bruno Haible  writes:

> Simon Josefsson wrote:
>> I've found it to only be cost
>> effective to setup my own runners for platforms that gitlab doesn't
>> support natively, such as arm64 or ppc64el.
>
> For GitHub runners, hosting your own runners comes with security risks [1].
>
> Do GitLab runners have the same security risks? (I.e. If, on GitLab, I fork
> one of your projects, add code, then trigger the CI, does my code then run
> on your machine?)

I think you have to push your code as a merge request back into the
original project to trigger the CI to run on hosted runners on gitlab.
Runners are project-specific, so if you fork project
gitlab.com/gnu/whatever into gitlab.com/user/whatever the runner
associated with the gnu-project till not run for gitlab.com/user pushes.
However it will run if you push the commit back into a merge request
that ends up on gitlab.com/gnu/whatever.  What is actually executed
depends on .gitlab-ci.yml content, but that is modifyable by the user
too so any user can in theory run code on any runner associated with any
public project that enables merge requests.

I think the gitlab recommended way to deal with this is to have
protected branches, and to setup protected workflows.  Then you can
provide additional access for protected workflows only.  Merge requests
will not trigger a workflow on a protected branch.  You can probably
setup a runner to only run commits on protected branches, which somewhat
mitigate this problem.

However I think the details are unimportant: when you set up a
gitlab/github runner you are fundamentally authorizing
gitlab.com/github.com to run code that you cannot audit on that machine.
Thus the only reasonable way to approach this is to assume that you will
run malicious code.  If the code comes from a user on gitlab/github or
someone who gained access to gitlab/github internal systems doesn't
really matter.  My conclusion is that the only responsible way to host a
runner is to do it on throw-away machines and be prepared to re-install
on a new machine, and to produce an audit trail for everything going
through runners.  For me, the advantages of using gitlab/github runners
(e.g., the entire CI/CD test harness) outweigh the risks here, but there
are several unresolved risks to consider.

/Simon

signature.asc
Description: PGP signature

Re: De-vendoring gnulib in Debian packages

Simon Josefsson wrote:
> Finally, while this is somewhat gnulib specific, I think the practice
> goes beyond gnulib

Yes, gnulib-tool for modules written in C is similar to

  * 'npm install' for JavaScript source code packages [1],
  * 'cargo fetch' for Rust source code packages [2],

except that gnulib-tool is simpler: it fetches from a single source location
only.

How does Debian handle these kinds of source-code dependencies?

Bruno

[1] 
https://nodejs.org/en/learn/getting-started/an-introduction-to-the-npm-package-manager
[2] https://doc.rust-lang.org/cargo/commands/cargo-fetch.html

Re: continuous integrations — own runners

2024-05-11 Thread Simon Josefsson via Gnulib discussion list

Simon Josefsson wrote:
> I've found it to only be cost
> effective to setup my own runners for platforms that gitlab doesn't
> support natively, such as arm64 or ppc64el.

For GitHub runners, hosting your own runners comes with security risks [1].

Do GitLab runners have the same security risks? (I.e. If, on GitLab, I fork
one of your projects, add code, then trigger the CI, does my code then run
on your machine?)

Bruno

[1] 
https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#self-hosted-runner-security

De-vendoring gnulib in Debian packages

All, (going out to both debian-devel and bug-gnulib, please be
respectful of each community's different perspectives and trim Cc
when focus shifts to any Debian or gnulib specific topics)
(please pardon the accidental duplicate post to bug-gnulib...)

The content of upstream source code releases can largely be categorized
into 1) the actual native source-code from the upstream supplier, 2)
pre-generated artifacts from build tools (e.g., ./configure script) and
3) third-party maintained source code (e.g., config.guess or getopt.c).
The files in 3) may be referred to as "vendoring". The habit of
including vendored and pre-generated artifacts is a powerful and
successful way to make release tarballs usable for users, going back to
the 1980's. This habit pose some challenges for packaging though:

1) Pre-generated files (e.g., ./configure) should be re-generated to
make sure the package is built from source code, and to allow patches
on the toolchain used to generate the pre-generated files to have any
effect. Otherwise we risk using pre-generated files created using
non-free or non-public tools, which if I understand correctly against
Debian main policy. Verifying that this happens for all
pre-generated files in an upstream tarball is complicated, fragile
and tedious work. I think it is simple to find examples of mistakes
in this area even for important top-popcon Debian packages. The
current approach of running autoreconf -fi is based on a
misunderstanding: autoreconf -fi is documented to not replace certain
files with newer versions:
https://lists.nongnu.org/archive/html/bug-gnulib/2024-04/msg00052.html

2) If a security problem in vendored code is discovered, the security
team may have to patch 50+ packages if the vendor origin is popular.
Maybe even different versions of the same vendored code has to be
patched.

3) Auditing the difference between the tarball and what is stored in
upstream version control system (VCS) is challenging. The xz
incident exploited the fact that some pre-generated files aren't
included in upstream VCS. Some upstream react to this by adding all
pre-generated artifacts to VCS -- OpenSSH seems to take the route of
adding the generated ./configure script to git, which moves that file
from 3) to 1) but the problem is remaining.

4) Auditing for license compliance is challenging, since not only do we
have to audit all upstream's code but we also have to audit the
license of pre-generated files and vendored source-code.

There are probably more problems involved, and probably better ways to
articulate the problems than what I managed to do above. The Go and
Rust ecosystems solve some of these issues, which has other consequences
for packaging. We have largely ignored that the same challenges apply
to many C packages, and I'm focusing on those that uses gnulib --
https://www.gnu.org/software/gnulib/ -- gzip, tar, grep, m4, sed, bison,
awk, coreutils, grub, libiconv, libtasn1, libidn2, inetutils, etc:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=users.txt

Solving all of the problems for all packages will require some work and
will take time. I've started to see if we can make progress on the
gnulib-related packages. I'm speaking as contributor to gnulib and
maintainer of a couple of Debian packages, but still learning to
navigate -- the purpose of this post is to describe what I've done for
libntlm and ask for feddback to hopefully make this into a re-usable
pattern that can be applied to more packages. It would be great to
improve collaboration on these topics between GNU and Debian.

So let's turn this post into a recipe for Debian maintainers of packages
that use gnulib to follow for their packages. I'm assuming git for now
on, but feel free to mentally s/git/$VCS/.

The first step is to establish an upstream tarball that you want to work
with. There are too many opinions floating around on this to make any
single solution a pre-requisite so here are the different approaches I
can identify, ordered by my own preference, and the considerations with
each.

1) Use upstream's PGP signed git-archive tarball.

See my recent blog posts for this new approach. The key property
here is that there is no need to audit difference between upstream
tarball and upstream git.

https://blog.josefsson.org/2024/04/01/towards-reproducible-minimal-source-code-tarballs-please-welcome-src-tar-gz/

https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/

2) Use upstream's PGP signed tarball.

This is the current most common and recommended approach, as far as I
know.

3) Create a PGP signed git-archive tarball.

If upstream doesn't publish PGP signed tarballs, or if there is a
preference from upstream or from you as Debian package maintainer to
not do 1) or 2), then create a minimal source-only copy of the git
archive and sign

De-vendoring gnulib in Debian packages

2024-05-11 Thread Simon Josefsson via Gnulib discussion list

All, (going out to both debian-devel and bug-gnulib, please be
respectful of each community's different perspectives and trim Cc
when focus shifts to any Debian or gnulib specific topics)

4) Auditing for license compliance is challenging, since not only do we
have to audit all upstream's code but we also have to audit the
license of pre-generated files and vendored source-code.

So let's turn this post into a recipe for Debian maintainers of packages
that use gnulib to follow for their packages. I'm assuming git for now
on, but feel free to mentally s/git/$VCS/.

1) Use upstream's PGP signed git-archive tarball.

See my recent blog posts for this new approach. The key property
here is that there is no need to audit difference between upstream
tarball and upstream git.

https://blog.josefsson.org/2024/04/01/towards-reproducible-minimal-source-code-tarballs-please-welcome-src-tar-gz/

https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/

2) Use upstream's PGP signed tarball.

This is the current most common and recommended approach, as far as I
know.

3) Create a PGP signed git-archive tarball.

git clone

Re: dealing with false alarms

For example, gcc does not have the notion that "variable X is initialized
if condition Y is met". It only distinguishes between "variable X is
initialized" and "variable X is uninitialized". This leads to many, many
false alarms.

>   3) In case of a false alarm, report it as a GCC bug and optionally add a
>  GCC_LINT conditional, so that
>- users can silence the warning if they want to and if the warning
>  category is generally somewhat useful,
>- readers of the code can see that the problem was already handled.

In some (few) cases, the code can be refactored in such a way that the
warning disappears _and_ the code become easier to understand. Such a
refactoring can be applied.

Example: 
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=3bb26f17cbb32c4129c4a26cd6122bd2227ddf05

Bruno

Re: gl_linked_iterator doesn't initialize all fields.

Hi Collin,

> Here is the function that it is warning about:
> 
> static gl_list_iterator_t _GL_ATTRIBUTE_PURE
> gl_linked_iterator (gl_list_t list)
> {
>   gl_list_iterator_t result;
> 
>   result.vtable = list->base.vtable;
>   result.list = list;
>   result.p = list->root.next;
>   result.q = >root;
> #if defined GCC_LINT || defined lint
>   result.i = 0;
>   result.j = 0;
>   result.count = 0;
> #endif
> 
>   return result;
> }

This code can be described as:
  "We initialize the result fields that are necessary to initialize.
   We know that some tools report that i, j, count are uninitialized,
   therefore we give you a way to silence the tools' reports: namely,
   compile with -DGCC_LINT."

> When compiling with -fanalyzer and including gl_anylinked_list2.h I
> see this:
> 
> In file included from gl_linked_list.c:29:
> gl_anylinked_list2.h: In function 'gl_linked_iterator':
> gl_anylinked_list2.h:952:10: warning: use of uninitialized value 
> 'result.count' [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
>   952 |   return result;
>   |  ^~
>   'gl_linked_iterator': events 1-3
> |
> |  940 |   gl_list_iterator_t result;
> |  |  ^~
> |  |  |
> |  |  (1) region created on stack here
> |  |  (2) capacity: 8 bytes
> |..
> |  952 |   return result;
> |  |  ~~   
> |  |  |
> |  |  (3) use of uninitialized value 'result.count' here

This is a false alarm.

Different tools exist for determining uninitialized values:
  - valgrind is the tool of choice. It has some false alarms, which
can be silenced through *.valgrind files. But other than that,
it is rock-solid.
  - gcc and clang have some data flow analysis. They can report uninitialized
values. gcc with -fanalyzer has many false alarms. In particular, from
this warning, you can see that it considers a 'return' statement of a
struct to be a "use" of all fields. Which is wrong.

> I couldn't find the reasoning why these were hidden behind 'lint' [1].

In Gnulib, we follow the approach that Paul has developed over the years:

  1) First, determine whether the warning pinpoints a problem or is a false
 alarm.

  2) In case of a problem, fix the problem in the code.

  3) In case of a false alarm, report it as a GCC bug and optionally add a
 GCC_LINT conditional, so that
   - users can silence the warning if they want to and if the warning
 category is generally somewhat useful,
   - readers of the code can see that the problem was already handled.

The rationale of this approach is:

  * The code is ultimately what we want to maintain for 20 and more years.
Whereas the capabilities of static analyzers evolve over time. It is
well possible that in 10 years the GCC analyzer has this fixed. If we
were to throw away the '#if', as you suggest, we would no longer know
that this piece of code can be optimized.

  * We want to pressure GCC, to improve their diagnostics. If we were to
just silence the warning by adding unconditional initializations, there
would not be pressure on GCC.

  * Last not least, we don't want unnecessary code to be executed. We are
programming C, not C++, precisely because we want to keep control over
which code gets executed.

> But my instinct tells me these initializations should be done
> unconditionally so undefined behavior is avoided.

There is no undefined behaviour here, only a false alarm.

Bruno

doc: Mention module execinfo

In doc/glibc-headers/execinfo.texi, the apparent contradiction between
  "Gnulib module: ---"
and
  "the Gnulib substitute implementation is just a stub"
caught my eye.


2024-05-11  Bruno Haible  

doc: Mention module execinfo.
* doc/glibc-headers/execinfo.texi: Mention module execinfo.
* doc/glibc-functions/backtrace.texi: Likewise.
* doc/glibc-functions/backtrace_symbols.texi: Likewise.
* doc/glibc-functions/backtrace_symbols_fd.texi: LIkewise.

diff --git a/doc/glibc-functions/backtrace.texi 
b/doc/glibc-functions/backtrace.texi
index d1e8ad6df9..b9a56094c1 100644
--- a/doc/glibc-functions/backtrace.texi
+++ b/doc/glibc-functions/backtrace.texi
@@ -17,19 +17,21 @@
 
@uref{https://www.kernel.org/doc/man-pages/online/pages/man3/backtrace.3.html,,man
 backtrace}.
 @end itemize
 
-Gnulib module: ---
+Gnulib module: execinfo
 
 Portability problems fixed by Gnulib:
 @itemize
-@end itemize
-
-Portability problems not fixed by Gnulib:
-@itemize
 @item
 This function is missing on many platforms:
 FreeBSD 9.3, NetBSD 6.1, OpenBSD 6.9, Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 
10, Cygwin 2.9, mingw, MSVC 14, Android API level 32.
+@end itemize
 
+Portability problems not fixed by Gnulib:
+@itemize
 @item
 The second argument is of type @code{size_t}, not @code{int}, on some 
platforms:
 FreeBSD, NetBSD, OpenBSD.
+@item
+On platforms where the function is missing,
+the Gnulib substitute implementation is just a stub, and does nothing.
 @end itemize
diff --git a/doc/glibc-functions/backtrace_symbols.texi 
b/doc/glibc-functions/backtrace_symbols.texi
index f55730f6c2..f63e263a81 100644
--- a/doc/glibc-functions/backtrace_symbols.texi
+++ b/doc/glibc-functions/backtrace_symbols.texi
@@ -17,19 +17,21 @@
 
@uref{https://www.kernel.org/doc/man-pages/online/pages/man3/backtrace_symbols.3.html,,man
 backtrace_symbols}.
 @end itemize
 
-Gnulib module: ---
+Gnulib module: execinfo
 
 Portability problems fixed by Gnulib:
 @itemize
-@end itemize
-
-Portability problems not fixed by Gnulib:
-@itemize
 @item
 This function is missing on many platforms:
 FreeBSD 9.3, NetBSD 6.1, OpenBSD 6.9, Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 
10, Cygwin 2.9, mingw, MSVC 14, Android API level 32.
+@end itemize
 
+Portability problems not fixed by Gnulib:
+@itemize
 @item
 The second argument is of type @code{size_t}, not @code{int}, on some 
platforms:
 FreeBSD, NetBSD, OpenBSD.
+@item
+On platforms where the function is missing,
+the Gnulib substitute implementation is just a stub, and does nothing.
 @end itemize
diff --git a/doc/glibc-functions/backtrace_symbols_fd.texi 
b/doc/glibc-functions/backtrace_symbols_fd.texi
index 1240837d43..fe97b44b35 100644
--- a/doc/glibc-functions/backtrace_symbols_fd.texi
+++ b/doc/glibc-functions/backtrace_symbols_fd.texi
@@ -17,19 +17,21 @@
 
@uref{https://www.kernel.org/doc/man-pages/online/pages/man3/backtrace_symbols_fd.3.html,,man
 backtrace_symbols_fd}.
 @end itemize
 
-Gnulib module: ---
+Gnulib module: execinfo
 
 Portability problems fixed by Gnulib:
 @itemize
-@end itemize
-
-Portability problems not fixed by Gnulib:
-@itemize
 @item
 This function is missing on many platforms:
 FreeBSD 9.3, NetBSD 6.1, OpenBSD 6.9, Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 
10, Cygwin 2.9, mingw, MSVC 14, Android API level 32.
+@end itemize
 
+Portability problems not fixed by Gnulib:
+@itemize
 @item
 The second argument is of type @code{size_t}, not @code{int}, on some 
platforms:
 FreeBSD, NetBSD, OpenBSD.
+@item
+On platforms where the function is missing,
+the Gnulib substitute implementation is just a stub, and does nothing.
 @end itemize
diff --git a/doc/glibc-headers/execinfo.texi b/doc/glibc-headers/execinfo.texi
index 7589b2cc18..bb1372ed51 100644
--- a/doc/glibc-headers/execinfo.texi
+++ b/doc/glibc-headers/execinfo.texi
@@ -17,7 +17,7 @@
 
@uref{https://www.kernel.org/doc/man-pages/online/pages/man3/backtrace.3.html,,man
 backtrace}.
 @end itemize
 
-Gnulib module: ---
+Gnulib module: execinfo
 
 Portability problems fixed by Gnulib:
 @itemize

Re: doc: Mention backtrace functions supported on BSD.

Hi Collin,

> FreeBSD, NetBSD, and OpenBSD support backtrace, backtrace_symbols, and
> backtrace_symbols_fd except they use 'size_t' for the second argument [1].
> 
> The man pages seem to agree that FreeBSD gained support in version
> 10.0 [1]. NetBSD and OpenBSD both gained support in version 7.0 [2] [3].

Thanks.

To complement your search, I use the git repo (FreeBSD) or CVS repo (NetBSD,
OpenBSD). My findings agree with yours:

FreeBSD  src/contrib/libexecinfo/execinfo.h
 added on 2013-08-23
 https://en.wikipedia.org/wiki/FreeBSD_version_history
 present in 10.0.0, missing in 9.3.0

NetBSD   src/lib/libexecinfo/execinfo.h
 added on 2012-05-27
 https://en.wikipedia.org/wiki/NetBSD#Releases 
http://www.netbsd.org/releases/formal.html
 present in 7.0, missing in 6.1

OpenBSD  src/gnu/lib/libexecinfo/execinfo.h
 added on 2021-06-09
 https://en.wikipedia.org/wiki/OpenBSD#Releases
 present in 7.0, missing in 6.9

In the documentation, if a function was added in a certain OS release, we still
mention it as missing in the previous OS release, because the goal of the
documentation is to tell the user what to expect. And it's the user who decides
whether portability to OpenBSD version 6.9 is relevant for them, not us.
Also I still have VMs for FreeBSD 5 and OpenBSD 6.x, and if the behaviour
on these VMs is different than on the newest versions, I want to know why.

Also, together with these functions comes a header file, , which
we document in doc/glibc-headers/execinfo.texi.


2024-05-11  Bruno Haible  

doc: Update regarding backtrace functions on *BSD.
* doc/glibc-functions/backtrace.texi: Mention in which *BSD releases
this function was missing.
* doc/glibc-functions/backtrace_symbols.texi: Likewise.
* doc/glibc-functions/backtrace_symbols_fd.texi: LIkewise.
* doc/glibc-headers/execinfo.texi: Update *BSD versions.

diff --git a/doc/glibc-functions/backtrace.texi 
b/doc/glibc-functions/backtrace.texi
index c44f077191..d1e8ad6df9 100644
--- a/doc/glibc-functions/backtrace.texi
+++ b/doc/glibc-functions/backtrace.texi
@@ -27,9 +27,9 @@
 @itemize
 @item
 This function is missing on many platforms:
-Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 10, Cygwin 2.9, mingw, MSVC 14, 
Android API level 32.
+FreeBSD 9.3, NetBSD 6.1, OpenBSD 6.9, Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 
10, Cygwin 2.9, mingw, MSVC 14, Android API level 32.
 
 @item
 The second argument is of type @code{size_t}, not @code{int}, on some 
platforms:
-FreeBSD 10.0, NetBSD 7.0, OpenBSD 7.0.
+FreeBSD, NetBSD, OpenBSD.
 @end itemize
diff --git a/doc/glibc-functions/backtrace_symbols.texi 
b/doc/glibc-functions/backtrace_symbols.texi
index 65903b9da0..f55730f6c2 100644
--- a/doc/glibc-functions/backtrace_symbols.texi
+++ b/doc/glibc-functions/backtrace_symbols.texi
@@ -27,9 +27,9 @@
 @itemize
 @item
 This function is missing on many platforms:
-Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 10, Cygwin 2.9, mingw, MSVC 14, 
Android API level 32.
+FreeBSD 9.3, NetBSD 6.1, OpenBSD 6.9, Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 
10, Cygwin 2.9, mingw, MSVC 14, Android API level 32.
 
 @item
 The second argument is of type @code{size_t}, not @code{int}, on some 
platforms:
-FreeBSD 10.0, NetBSD 7.0, OpenBSD 7.0.
+FreeBSD, NetBSD, OpenBSD.
 @end itemize
diff --git a/doc/glibc-functions/backtrace_symbols_fd.texi 
b/doc/glibc-functions/backtrace_symbols_fd.texi
index 30ce4a2a06..1240837d43 100644
--- a/doc/glibc-functions/backtrace_symbols_fd.texi
+++ b/doc/glibc-functions/backtrace_symbols_fd.texi
@@ -27,9 +27,9 @@
 @itemize
 @item
 This function is missing on many platforms:
-Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 10, Cygwin 2.9, mingw, MSVC 14, 
Android API level 32.
+FreeBSD 9.3, NetBSD 6.1, OpenBSD 6.9, Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 
10, Cygwin 2.9, mingw, MSVC 14, Android API level 32.
 
 @item
 The second argument is of type @code{size_t}, not @code{int}, on some 
platforms:
-FreeBSD 10.0, NetBSD 7.0, OpenBSD 7.0.
+FreeBSD, NetBSD, OpenBSD.
 @end itemize
diff --git a/doc/glibc-headers/execinfo.texi b/doc/glibc-headers/execinfo.texi
index ea25e562e9..7589b2cc18 100644
--- a/doc/glibc-headers/execinfo.texi
+++ b/doc/glibc-headers/execinfo.texi
@@ -23,7 +23,7 @@
 @itemize
 @item
 This header file is missing on some platforms:
-FreeBSD 6.0, NetBSD 5.0, OpenBSD 6.7, Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 
10, Cygwin, mingw, MSVC 14, Android 9.0.
+FreeBSD 9.3, NetBSD 6.1, OpenBSD 6.9, Minix 3.1.8, AIX 5.1, HP-UX 11, Solaris 
10, Cygwin, mingw, MSVC 14, Android 9.0.
 @end itemize
 
 Portability problems not fixed by Gnulib:

gl_linked_iterator doesn't initialize all fields.

When compiling with -fanalyzer and including gl_anylinked_list2.h I
see this:

In file included from gl_linked_list.c:29:
gl_anylinked_list2.h: In function 'gl_linked_iterator':
gl_anylinked_list2.h:952:10: warning: use of uninitialized value 'result.count' 
[CWE-457] [-Wanalyzer-use-of-uninitialized-value]
  952 |   return result;
  |  ^~
  'gl_linked_iterator': events 1-3
|
|  940 |   gl_list_iterator_t result;
|  |  ^~
|  |  |
|  |  (1) region created on stack here
|  |  (2) capacity: 8 bytes
|..
|  952 |   return result;
|  |  ~~   
|  |  |
|  |  (3) use of uninitialized value 'result.count' here


Here is the function that it is warning about:

static gl_list_iterator_t _GL_ATTRIBUTE_PURE
gl_linked_iterator (gl_list_t list)
{
  gl_list_iterator_t result;

  result.vtable = list->base.vtable;
  result.list = list;
  result.p = list->root.next;
  result.q = >root;
#if defined GCC_LINT || defined lint
  result.i = 0;
  result.j = 0;
  result.count = 0;
#endif

  return result;
}

I couldn't find the reasoning why these were hidden behind 'lint' [1].
But my instinct tells me these initializations should be done
unconditionally so undefined behavior is avoided.

Should these lint checks be removed or am I missing something?

[1] 
https://git.savannah.gnu.org/cgit/gnulib.git/commit/lib/gl_anylinked_list2.h?id=a42a50dc6f5c48c557920c21c8f05d31f26fea73

Collin

doc: Mention backtrace functions supported on BSD.