Hi Paul,
On 5/11/24 12:08 PM, Paul Eggert wrote:
> diff --git a/m4/stdbit_h.m4 b/m4/stdbit_h.m4
> new file mode 100644
> index 00..9ce3cb3146
> --- /dev/null
> +++ b/m4/stdbit_h.m4
> @@ -0,0 +1,19 @@
> +# stddef_h.m4
> +# serial 1
I see that you use my method of making sure files have lic
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: U
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.
>
> gn
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:
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
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
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.sp
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-
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-6
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.coun
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,
| ^~~
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 por
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'v
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,
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: Cont
* 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:
* te
* 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-heade
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 e
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 sour
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/gc
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 runner
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
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
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 sourc
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)
The content of upstream source code releases can largely be categorized
into 1) the actual native
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 optional
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 = &l
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 exec
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
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-uninitializ
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].
Collin
[1]
31 matches
Mail list logo
