On 5/23/24 3:01 PM, Bruno Haible wrote:
> The mbrtoc32 function, newly added in Cygwin 3.5.0, is buggy.
>
> These two patches provide a workaround (at the cost of deactivating
> the GB18030 locale support in Cygwin), and add a two test cases.
Looks good. Thanks for all the Cygwin fixes.
Collin
On 5/23/24 5:55 AM, Bruno Haible wrote:
>> I just noticed in the Cygwin 32 logs that c32is* tests pass while on
>> Cygwin 64 they fail.
>
> That's because the Cygwin 64 build is version 3.5.3, whereas the Cygwin 32
> build is version 3.3.6. Look at the 'cygcheck' output in the log.
Hahaha. well
Hi Bruno,
On 5/23/24 3:48 AM, Bruno Haible wrote:
> On Cygwin 3.4.6, but not on Cygwin 3.5.3, I see these test failures:
>
> FAIL: test-areadlinkat.exe
> FAIL: test-areadlinkat-with-size.exe
> FAIL: test-readlinkat.exe
>
> The cause is an errno value EBADF, where EINVAL would be better.
> Not
Hi Bruno,
On 5/22/24 7:53 AM, Bruno Haible wrote:
> Here's a technique that allows you to build on platforms for which you don't
> have a machine without direct access.
>
> A machine with direct access (either a VM, or a machine with ssh access [1])
> is
> preferred, since it's more easy to
I've pushed this patch updating end-of-life.txt in maint-tools.git.
NetBSD released 8.3 as a final security release, major version 8 is
not longer supported [1].
OpenBSD released 7.5 and therefore 7.3 is no longer supported [2] [3].
diff --git a/end-of-life.txt b/end-of-life.txt
index
Hi Bruno,
On 5/21/24 5:43 PM, Bruno Haible wrote:
> The new patch is good. OK to push.
Done, thanks.
>> Interesting way to think about it, thanks. Do you have a strong math
>> background? It has been a while since I looked at that interval
>> notation.
>
> Oh, I learned the interval notation
tart, end):
startend
^ ^
| |
[1] [2] [3] [4] [5] [6] [7] [8]
'/' 'b' 'i' 'n' '/' 's' 'h' '\0'
I guess that probably makes everything easier for others to follow. I
didn't think about it too much until you me
On 5/21/24 10:10 AM, Paul Eggert wrote:
> Sometimes I wish 'bootstrap' and 'configure' were less chatty.
+1, but I can't think of a way to do so without hiding bugs.
Usually I just redirect it to a file since it is easier to read there.
Collin
Hi Bruno,
On 5/21/24 2:13 PM, Bruno Haible wrote:
>> I pushed the attached patch adding the #if defined __illumos__.
>
> It apparently has the desired effect. So, let me do the same thing with
> the test-trim3.sh test, that fails like this:
>
> FAIL: test-trim3.sh
> ===
>
>
On 5/21/24 6:45 AM, Bruno Haible wrote:
> The CI runs the Solaris 11 and Solaris 11 OmniOS tests as root, and shows
> these two test failures:
>
> FAIL: test-access
> FAIL: test-euidaccess
>
> This occurs because although the file does not have the 'x' bit set,
> for root faccessat() returns 0.
Collin
[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00330.htmlFrom d7beec8902330587cda62af308d1ea629b883d7d Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Tue, 21 May 2024 02:40:14 -0700
Subject: [PATCH] fnmatch tests: Avoid test failure on OmniOS.
Using the GB18030 locale OmniOS doesn't match U+00D7 MULTIPLIC
Hi Bruno,
I was taking a look at the CI stuff you wrote. Nice work, it seems
really helpful.
I saw this test failure:
FAIL: test-fnmatch-5.sh
===
../../gltests/test-fnmatch.c:898: assertion 'fnmatch ("x[[:punct:]]y",
"x\241\301y", 0) == 0' failed
Stack trace:
0x410355 main
track of if a stream needs to be
locked? I'm thinking about single-threaded programs that don't define
GNULIB_GETUSERSHELL_SINGLE_THREAD. I imagine the stream doesn't locked
x10 more, but a status flag is checked x10 more or something.
CollinFrom 9b67292f9dd7c1b0ecfd15993ee43a99eb557b76 Mon Sep
doc/posix-functions/futimens.texi
doc/posix-functions/utimensat.texi
CollinFrom 7e842de9d80ddd94abd61f529702b2e27f31c175 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Mon, 20 May 2024 14:23:41 -0700
Subject: [PATCH 1/2] utimensat, utimens: Work around NetBSD 10.0 bugs.
* lib/utimens.c (fdutime
Hi Bruno,
On 5/20/24 12:40 PM, Bruno Haible wrote:
>> Interesting. I just learned what a Coverity scan is. Do I have to have
>> permission to view the defects?
>
> I think one needs permission to view and classify these defects, yes.
> But it's more boring than anything else, since more than 90%
Hi Paul,
On 5/20/24 9:13 AM, Paul Eggert wrote:
> Gnulib does not support glibc 2.1.x and older, so this should not be a
> problem when porting to glibc. However, I worried that other platforms might
> have the bug, until I noticed that m4/byteswap.m4 already inadvertently tests
> for it. I
Hi Bruno,
On 5/20/24 3:28 AM, Bruno Haible wrote:
>> It looks like the current code wants drive-prefixes accepted, i.e.
>> 'c:/ugly/windows/stuff'.
>
> ?? I don't see such code in gnulib/lib/getusershell.c.
It is defined in the 'ADDITIONAL_DEFAULT_SHELLS' macro [1]:
#if ! defined
it in newer versions of NetBSD.
The bug report got addressed today. In the following commit [1]:
PR/58266: Collin Funk: Fail if from == to, like FreeBSD and Linux. The test
is done in dup3 before any other tests so even if a bad descriptor it is
passed we will return EINVAL not EBADFD lik
On 5/19/24 7:48 PM, Collin Funk wrote:
> It looks like the current code wants drive-prefixes accepted, i.e.
> 'c:/ugly/windows/stuff'.
>
> That sort of breaks the behavior of glibc and BSD where:
>
> input -> getusershell () output
> 'bin/bash' -> '/bash
On 5/19/24 7:17 PM, Bruno Haible wrote:
> You don't need an Alpine Linux machine to debug this. You can debug it
> on a glibc system like this:
> 1. create a testdir for the module getusershell,
> 2. configure through
>ac_cv_func_getusershell=no ./configure
> 3. use the unit test, or
Hi Bruno,
On 5/19/24 5:03 PM, Bruno Haible wrote:
> Perfect. Thanks a lot!
Sadly, it looks like this uncovered that the gnulib version is buggy
too.
Given this etc/shells:
# valid login shells
/bin/sh # abc
/bin/ash # 123
/bin/bash # def
ngeLog
+++ b/ChangeLog
@@ -1,3 +1,20 @@
+2024-05-19 Collin Funk
+
+ getusershell: Work around musl bugs.
+ Reported by Bruno Haible in
+ <https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00261.html>.
+ * doc/glibc-functions/getusershell.texi: Mention
On 5/19/24 2:29 AM, Collin Funk wrote:
> With that those two test cases seem to fail for the same reason as the
> others:
>
> $ ./gltests/test-fdutimensat
> test-utimens.h:149: assertion 'ctime_compare (, ) < 0' failed
> $ ./gltests/test-utimensat
>
Hi Bruno,
On your NetBSD test failures you had these:
> FAIL: test-fdutimensat
> ==
>
> ../../gltests/test-utimens.h:75: assertion 'func (BASE "file", ts) == -1'
> failed
> FAIL test-fdutimensat (exit status: 134)
>
> FAIL: test-futimens
> ===
>
>
Hi Bruno,
On 5/18/24 12:16 AM, Bruno Haible wrote:
>> I'll submit a bug report on the musl lists now.
>
> Thanks.
I submitted a report yesterday but forgot to link here [1].
>> I don't think this function is used too much
>
> Probably no one noticed the bug before, because the typical use of
Hi Paul,
Patch looks good.
On 5/18/24 7:04 PM, Paul Eggert wrote:
> Port to platforms lacking 64-bit integers (something that Emacs
> still attempts to do, in theory) by adding an u64bswap primitive
> to u64.h and using that, instead of using bswap_64. This fixes a
> bug I made in commit
llinFrom c7398c508d7e0222c1d7a74c14d93b23bf57fe05 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Sat, 18 May 2024 17:34:09 -0700
Subject: [PATCH] dup3: Update documentation and expected test results.
* doc/glibc-functions/dup3.texi: Mention NetBSD bug fixed by the Gnulib
implementation after the
Hi Bruno,
On 5/18/24 4:54 AM, Bruno Haible wrote:
>> +/* On NetBSD dup3 is a no-op when oldfd == newfd, but we expect
>> + an error with errno == EINVAL. */
>
> (What is "we", and who expects something from whom?)
> I would find it less confusing if written like this:
t insert regular tabs.
> Other than that, it looks correct.
I've applied this patch. Same as before but with those two things
fixed.
CollinFrom 83dd4db866cc5dde2fddcf1944f3b5cc3732e48e Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Sat, 18 May 2024 06:36:55 -0700
Subject: [PATCH] endian: M
this module
to mess with your CI jobs.
Collin From 670b8be73f4b79d4a6993dafcd12ae81721a85b6 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Sat, 18 May 2024 06:36:55 -0700
Subject: [PATCH] endian: Make sure system headers can be included.
Reported by Bruno Haible in
<https://lists.gnu.org/
Hi Bruno,
On 5/18/24 4:12 AM, Bruno Haible wrote:
> While testing a testdir for module 'endian' on gcc110.fsffrance.org
> (in the GCC compilefarm), I get a compilation error. This machine has
> a pretty old libc (glibc 2.17), but that ought to work anyway.
Oops, sorry.
I sent a request for a
Hi Bruno,
On 5/18/24 3:42 AM, Bruno Haible wrote:
> An interesting approach. But I think this added code comes too early:
> In case of oldfd == newfd && newfd < 0, it would fail with EINVAL instead
> of EBADF.
>
> How about trying the system call first, and test for newfd == oldfd only if
> that
Hi Bruno,
On 5/17/24 2:10 PM, Bruno Haible wrote:
> On NetBSD 9.0 and 10.0, I always see the same tests fail:
>
> FAIL: test-dup3
> ===
>
> ../../gltests/test-dup3.c:113: assertion 'dup3 (fd, fd, o_flags) == -1' failed
> FAIL test-dup3 (exit status: 134)
It looks like dup3 behaves
appreciated, to catch any typos
I may have made there. :)
Collin
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=31749
[2] https://austingroupbugs.net/view.php?id=1799From 95f7085c87236bea297f9251ecb58e0bd821552c Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Sat, 18 May 2024 00:10:33 -0700
Subject
...
CollinFrom f77eb82cec43e043762c7e746375bc1879aa4849 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Fri, 17 May 2024 18:53:51 -0700
Subject: [PATCH] getusershell tests: Fail if empty lines are returned.
* tests/test-getusershell.c (first_pass): Check the result of malloc.
Make sure '\0' isn't
On 5/17/24 3:49 PM, Paul Eggert wrote:
> POSIX does not require uint64_t, and the C standard
> does not require uint16_t or uint32_t either, so port
> to platforms that lack these types. The POSIX limitation
> is the only significant one in practice. I ran into this
> issue when updating Emacs,
On 5/17/24 4:51 PM, Bruno Haible wrote:
> I think this produces wrong code with gcc 4.4.7 and older. See:
>
> -- foo.c --
> unsigned long long x = 0xff00;
> ---
>
> $ gcc -Wall -S
On 5/17/24 2:10 PM, Bruno Haible wrote:
> Since I don't have time to investigate them and, OTOH, I don't want that
> the NetBSD test failures mark the entire continuous integration run as
> "failed", here are patches to mark them as expected failures.
Seems reasonable. Perhaps it is worth
On 5/17/24 6:45 AM, Bruno Haible wrote:
>> It also looks like musl will return empty lines (getline () with
>> length 1), which I believe is incorrect from the FreeBSD man page
>> description.
>
> So, once you have a musl libc VM yourself, you are ready for reporting
> your first musl libc bug.
Hi Bruno,
On 5/17/24 5:59 AM, Bruno Haible wrote:
> The test fails on Alpine Linux.
>
>
> FAIL: test-getusershell
> ===
>
> ../../gltests/test-getusershell.c:53: assertion 'ptr[0] != '#'' failed
> Aborted (core dumped)
> FAIL test-getusershell (exit status: 134)
Hahaha, I
On 5/17/24 2:38 AM, Bruno Haible wrote:
> Now we can use the usual doc structure.
>
>
> 2024-05-17 Bruno Haible
>
> putenv-gnu: Update documentation.
> * doc/posix-functions/putenv.texi: Refer also to the glibc
> documentation. Use the usual doc structure.
Looks good.
In the NEWS file:
2009-04-01 visibility Renamed to lib-symbol-visibility.
The commit that did this missed a reference to 'visibility' in the
documentation. This patch fixes it.
CollinFrom fe8453457c44194354bea89347f713562f67aae2 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Fri
in.h.
I'm assuming that _GL_[module-name]_(rest-of-macro) can be assumed
safe?
CollinFrom 73541d459cdd964e71f40ad447e50a7253a6f20d Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Thu, 16 May 2024 23:18:16 -0700
Subject: [PATCH] byteswap: Use __has_builtin portably.
Reported by Paul Eggert in
enough. If not the test cases I added in patch 2 should catch it at
least.
[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00188.html
CollinFrom 0858943ba21449b1f8fd0c0ed8c2342cdac3c374 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Thu, 16 May 2024 20:37:14 -0700
Subject: [PATCH 1/2]
dir --dir=testdir1 --single-configure stdbit-h
Module list with included dependencies (indented):
c99
extern-inline
[...]
tests/test-stdbit-h.c
tests/test-stdbool.c
executing aclocal -I glm4
^C/home/collin/.local/src/gnulib/gnulib-tool.py: *** Stop.
CollinFrom 46be8fb69d76bed6cb4cc3d4ec55
. I ran the following in Coreutils:
./bootstrap --no-git --skip-po --gnulib-srcdir="$GNULIB_SRCDIR"
and everything worked fine. Notice and correct import, so hopefully no
breakage should occur. :)
CollinFrom 5d2987e6ca5a7d06b4135ab17314051d363621f2 Mon Sep 17 00:00:00 2001
From: Col
Hi Bruno,
On 5/16/24 5:45 AM, Bruno Haible wrote:
> The way to deal with it, that is most consistent with the rest of Gnulib,
> is as follows:
>
> - Rename the 'putenv' module to 'putenv-gnu'.
>
> - Also change its description from:
> putenv() function: change or add an environment
Hi Bruno,
On 5/16/24 3:19 AM, Bruno Haible wrote:
>> Is there a reason why the Gnulib putenv module isn't mentioned on this
>> line or can I apply this diff with a ChangeLog entry?
>
> It is mentioned at the end of this file.
I saw. I was thinking maybe it should be mentioned on that line
mode 100644 tests/test-putenv.c
diff --git a/ChangeLog b/ChangeLog
index 7690099cde..8bccdfd2e1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2024-05-16 Collin Funk
+
+ putenv: Add tests.
+ * tests/test-putenv.c: New file.
+ * modules/putenv-tests: New file.
+
2024
Is there a reason why the Gnulib putenv module isn't mentioned on this
line or can I apply this diff with a ChangeLog entry?
diff --git a/doc/posix-functions/putenv.texi b/doc/posix-functions/putenv.texi
index b0ca4ab8b5..d9e15f5e38 100644
--- a/doc/posix-functions/putenv.texi
+++
On 5/15/24 8:45 PM, Bruno Haible wrote:
> Can you make gnulib-tool.py print a diagnostic in this case as well?
> It does not need to be exactly "caught signal SIGINT", like bash does.
> Just an indication that
> - gnulib-tool.py
> - is being terminated
> - due to a signal 2.
> Preferrably
e help.
$ gnulib-tool --create-testdir --dir testdir1
^C
$
CollinFrom 43ca9607f03b697df0dfc356ef1a3029551c9897 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Wed, 15 May 2024 20:25:38 -0700
Subject: [PATCH] gnulib-tool.py: Don't print tracebacks when Ctrl-C is
pressed.
MIME-Versio
On 5/15/24 12:03 PM, Paul Eggert wrote:
>> If we can ensure byteswap.h functions are defined as functions,
>> wouldn't it make sense to just define these as macros to them?
>
> Not sure why macros would be helpful. If functions suffice for good
> performance when compiling with -O2, it's better
Hi Bruno,
On 5/15/24 4:06 PM, Bruno Haible wrote:
> The module 'stdbit' defines 70 functions, grouped into 14 function-like
> macros. Most packages will only need 1 or 2 among these 14 function groups.
> (For example, diffutils needs only 'stdc_bit_width'.)
Maybe it makes sense to provided a
Hi Bruno,
On 5/15/24 3:06 AM, Bruno Haible wrote:
> I'm adding a signature test. (So far, we have a signature test for these
> functions only in C++ mode, in tests/test-unistd-c++.cc.)
Thanks! I would have added them if I saw them there.
Should all glibc functions have a signature check? For
Hi Pádraig,
On 5/13/24 2:32 PM, Pádraig Brady wrote:
> I've an 18 year old script template here that silences Ctrl-C spew:
> https://www.pixelbeat.org/talks/python/cli_skel.py
Ah, okay I think I understand this now. So basically the backtrace is
the default excepthook and your code skips running
/getusershell-tests
create mode 100644 tests/test-getusershell.c
diff --git a/ChangeLog b/ChangeLog
index e0c6141e88..bf05fbc522 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2024-05-15 Collin Funk
+
+ getusershell: Add tests.
+ * modules/getusershell-tests: New file
On 5/14/24 2:24 AM, Bruno Haible wrote:
> But the first line of this diagnostic looks strange, without an
> indication where it comes from. Recall our conventions:
> - For an error during option handling, prepend the absolute program name.
> - For an error due to the contents of some files,
r this mkdir issue. (I'll do it if you don't have the time.)
> Thanks.
Sorry, it took me a bit to get around to this. I've committed the
attached patch.
CollinFrom b2666d326a53dd24e2fc832e0c85b351d25fd0ee Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Tue, 14 May 2024 23:21:00 -0700
Subject:
megatestdir.
CollinFrom 719ce7d39e58b9311b51ac93d828fb26c2bcfbaf Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Mon, 13 May 2024 21:36:25 -0700
Subject: [PATCH] gnulib-tool.py: Don't continue creating testdirs when destdir
exists.
* pygnulib/GLError.py (GLError.__init__, GLError.__repr__)
On 5/13/24 7:45 PM, Paul Eggert wrote:
> I messed up. However, the shell implementation of gnulib-tool diagnoses my
> mistake right away, before going on its slow way:
>
> $ GNULIB_TOOL_IMPL=sh ./gnulib-tool --create-testdir --dir foo -h stdbit
> mkdir: cannot create directory ‘foo’: File
f we can ensure byteswap.h functions are defined as functions,
wouldn't it make sense to just define these as macros to them?
CollinFrom f4a34789c8f55161c1cab343a97511206761ff47 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Mon, 13 May 2024 15:05:33 -0700
Subject: [PATCH 1/2] byteswap: Use inline
Hi Paul,
On 5/11/24 12:08 PM, Paul Eggert wrote:
> diff --git a/modules/stdbit b/modules/stdbit
> index 6096869774..f70386566b 100644
> --- a/modules/stdbit
> +++ b/modules/stdbit
> @@ -7,9 +7,6 @@ lib/stdbit.in.h
> m4/stdbit_h.m4
>
> Depends-on:
> -count-leading-zeros
On 5/13/24 10:10 AM, Bruno Haible wrote:
> I find these comments useful, in particular in files that contains
> several classes, such as GLFileSystem.py.
>
> This is because I apparently work differently from you: When I open
> a source code file:
> - I do so in a window with at least 50 lines,
Hi Paul,
On 5/13/24 9:39 AM, Paul Eggert wrote:
> I realized that I invoked ' ./gnulib-tool --create-testdir --dir foo stdbit'
> with the wrong options so I interrupted it with control-C. It then gave me
> the following long traceback, which is not useful. I suggest shutting off the
> Python
On 5/13/24 8:12 AM, Bruno Haible wrote:
> For a new file that is not based on another file, it's sufficient to say
> "New file." No need to go into the details of what the file contains.
> The reason is that the purpose of a ChangeLog is "so that people investigating
> bugs in the future will know
Hi Bruno,
On 5/13/24 5:38 AM, Bruno Haible wrote:
>> Let me know if I missed anything. Other than the docs and test module
>> which I can do later today (assuming this patch is decent enough).
>
> The doc changes belong in the same commit. The tests module should be
> in a different commit, but
enough).
CollinFrom fe97691b765e57a9c5ea35dca5cb9502d284fb2b Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Mon, 13 May 2024 04:43:18 -0700
Subject: [PATCH] endian: New module.
* modules/endian: New file.
* lib/endian.in.h: New file, based on POSIX draft and glibc.
* m4/endian_h.m4: New file, checks
On 5/12/24 1:30 PM, Paul Eggert wrote:
> I sense a bit of confusion here. Although POSIX allows symbols
> like be16toh to be macros, I don't see where it allows be16toh(X) to evaluate
> X more than once, so an expression like be16toh(i++) has well-defined
> behavior even though it has a side
On 5/12/24 1:02 PM, Bruno Haible wrote:
> The simple fix to your worry is: Let the user use '-Wall' routinely.
> gcc has a warning option '-Wsequence-point', included in '-Wall'.
> clang has a warning option '-Wunsequenced', included in '-Wall'.
> The do the job, and I have not seen them produce
On 5/12/24 12:38 PM, Paul Eggert wrote:
>> Also if we can agree upon making sure these are defined as functions,
>> what is the proper way to test it in a configure script? My instinct
>> tells me that assigning a function pointer to bswap_16, etc. would
>> fail if they are macros
>
> I don't see
A few months ago there was a suggestion on emacs-devel to use
__builtin_bswap functions when available [1]. While I agree that GCC
can deal with the optimizations properly, I noted an important
difference between the macros in byteswap.h.in and inline functions
provided by glibc.
Using this test
Hi Bruno,
On 5/12/24 7:09 AM, Bruno Haible wrote:
> Now that we have unit tests for the backtrace* functions, let's see what
> they produce:
Nice work!
> Collin, feel free to report the FreeBSD, NetBSD, OpenBSD bugs if you have
> time for that. It's only by reporting bugs that we can trigger
On 5/12/24 8:23 AM, Paul Eggert wrote:
> Is this stuff documented somewhere in the .texi files? If not, I suppose it
> should be.
I'm not sure. The only reason I noticed was because I was working on
endian.h and using stdbit as a template since my m4 talents are lacking...
> Frankly I continue
On 5/12/24 4:39 AM, Collin Funk wrote:
> I left backtrace_symbols_fd untested because I did not see too much
> benefit in testing it. Its job is similar enough to backtrace_symbols
> but would require thinking about module dependencies and headers for
> create () and unlink (), or
Hi Bruno,
On 5/12/24 3:43 AM, Bruno Haible wrote:
> Reading through your test, I notice that when size == 0 && symbols != NULL,
> the symbols pointer is not freed. So I went to look deeper.
>
> Reading through the documentation at
>
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
' 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
Fr
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
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
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
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
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
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]
]
https://man.freebsd.org/cgi/man.cgi?query=backtrace=3=FreeBSD+11-current
[2] https://man.netbsd.org/backtrace.3
[3] https://man.openbsd.org/backtrace.3From 3db26a2864214ee13dc0f6662f32efab1426ee27 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Sat, 11 May 2024 00:58:44 -0700
Subject: [PATCH
ee4be3987b5bfb87a2d5a21c269d2f1ea249a316 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Wed, 8 May 2024 18:55:51 -0700
Subject: [PATCH] ftello: Prefer stdckdint to intprops.
* lib/ftello.c (ftello): Include stdckdint.h instead of intprops.h.
Prefer ckd_add to INT_ADD_OK.
* modules/ftello (Depends-on): Depend
On 5/8/24 12:47 AM, Collin Funk wrote:
>> With .sh, both fail. With .py, both succeed. Looks like a bug in
>> gnulib-tool.py: When the 'make' or 'make check' step fails, the entire
>> command should fail.
>
> I see what you mean. I'll have a look at fixing that right now.
Hi Bruno,
On 5/8/24 12:25 AM, Bruno Haible wrote:
>> I noticed Gnulib changed most of the *_WRAPV to the ckd_* variants at
>> some point. Is there a reason that INT_MULTIPLY_OK is still used in
>> base32 and base64 or can I apply the following patch?
>
> No particular reason. The patch is OK to
everyone that used it had it in
their module list or as a transitive dependency.
CollinFrom 9710c203220c73d9f3e1b604604157f76b1a821e Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Tue, 7 May 2024 21:47:17 -0700
Subject: [PATCH] base32, base64: Prefer stdckdint to intprops.
* lib/base32.c
insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index 21f4039dfe..b752fde065 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2024-05-07 Collin Funk
+
+ gnulib-tool.py: Handle module dependencies that cannot be found.
+ * pygnulib/GLModuleSystem.py
On 5/6/24 5:38 AM, Bruno Haible wrote:
>> sc_unsigned_int:
>> @prohibit=u''_int \
>> halt='don'\''t use u''_int; instead use unsigned int' \
>> $(_sc_search_regexp)
> Sounds good to me. My only suggestion is to move the sc_unsigned_long
> rule after the sc_unsigned_int
ve applied the attached patch.
CollinFrom 987535a15d4d2902818661feb6d6b363e4d7af2b Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Sat, 4 May 2024 23:46:02 -0700
Subject: [PATCH] gnulib-tool: Ignore autom4te.cache when using
GNULIB_TOOL_IMPL=sh+py.
Reported by Paul Eggert in:
<https://lists
On 5/4/24 11:07 PM, Paul Eggert wrote:
>> Since seems resonably portable,
>
> I assume you mean ? There's no on my Ubuntu system.
No, sorry maybe I worded my original email awkwardly. :)
I think all of the BSDs have which define:
#define LITTLE_ENDIAN 1234
#define BIG_ENDIAN 4321
On 5/4/24 8:17 AM, Bruno Haible wrote:
>> For CI, I am thinking it is best to ignore the typing warnings for the
>> time being. Since gnulib-tool.py needs a bit more refactoring for that
>> to be helpful. It was written before typing was a thing. :)
>
> Hmm. Is that refactoring, that you are
Hi Paul,
On 5/4/24 3:02 PM, Paul Eggert wrote:
> On 2024-05-04 13:45, Collin Funk wrote:
>> I can't reproduce this (using Fedora 40).
>
> That's odd, as I just now reproduced it on Fedora 40 x86-64 using the
> following from-scratch recipe:
I noticed in your emacs/output.0
On 5/4/24 3:02 PM, Paul Eggert wrote:
> The attached build log shows what I got. The last 'grep' command shows the
> bug, as lib/gnulib.mk.in uses HAVE_OFF64_T without defining it.
>
> This invocation of admin/merge-gnulib uses a nearly-empty environment and an
> empty home directory, to lessen
On 5/4/24 2:30 PM, Paul Eggert wrote:
>> But, I think the next POSIX revision has like Glibc which I
>> prefer.
>
> If the past is any guide, an advantage of the C23 version is that in
> the long run it is likely to be more portable. POSIX is an extension
> of C.
True. But I don't think C23 has
Hi Bruno,
On 5/4/24 7:52 AM, Bruno Haible wrote:
> And we're not yet done with the header file substitutes. One is still missing
> from Gnulib: [1]. The only thing that has changed since last year
> is that glibc 2.39 now has this header file [2]. But who will want to use it,
> as long as it's
Hi Paul,
On 5/4/24 9:03 AM, Paul Eggert wrote:
> Some sort of locale problem? The issue seems to be benign, except that it's a
> false positive when testing.
>
> To reproduce it, clone current gnulib (commit
> fde88b711c9b1df5b142444ac7b0bc2aa8892d3a) and current emacs (commit
>
1 - 100 of 506 matches
Mail list logo
