Thanks for reporting that. I installed this patch into Gnulib:
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=6457d2c190f47e2288c08f6a5e0dba412ff62855
and propagated it into Emacs master:
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=799f78a92c6c31f4d181390523b83d036020ede1
P
Unfortunately I had some trouble using that patch with GNU Emacs, which
wants to avoid bringing in a lot of Gnulib code for various reasons. The
trouble is that this change to nstrftime brings in the hard-locale
module, which brings in a bunch of other stuff.
To remove this dependency I instal
Problem reported by Po Lu in:
https://lists.gnu.org/r/bug-gnulib/2024-06/msg00015.html
* lib/ieee754.in.h (_IEEE754_BYTE_ORDER, _IEEE754_BIG_ENDIAN)
(_IEEE754_LITTLE_ENDIAN, _IEEE754_FLOAT_WORD_ORDER): New macros.
All uses of __BYTE_ORDER, __BIG_ENDIAN, __LITTLE_ENDIAN,
__FLOAT_WORD_ORDER changed t
I did:
> * tests/test-readlink.h (test_readlink): Add a test of /dev/null.
and now I get a failure of test-readlinkat:
FAIL: test-readlinkat
=
../../gltests/test-readlink.h:120: assertion 'result == -1 || buf[0] != '\\''
failed
Stack trace:
0x40243d print_stack_trace
On the Cygwin 3.3.6 machine at GitHub I see a test failure:
FAIL: test-supersede
../../gltests/test-supersede-open.h:109: assertion 'fd >= 0' failed
Stack trace:
0x4049fd print_stack_trace
../../gllib/abort-debug.c:40
0x4049fd _gl_pre_abort
../../gllib/abort-d
Paul Eggert wrote:
> N2956 has a typo. In this statement:
>
> "Similarly, GCC’s pure is less restricted than the new standard
> attribute [[reproducible]], and an implementation of the GCC feature is,
> syntax aside, an implementation of the new standard attribute."
>
> The words "less restrict
On 5/31/24 06:03, Bruno Haible wrote:
Basil L. Contovounesios wrote:
Isn't this saying that C23 [[reproducible]] is stricter than GCC pure?
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2956.htm#some-differences-with-gcc-const-and-pure
Yes: [1], section "Note on GCC attributes", also claim
Bruno Haible [2024-05-31 15:03 +0200] wrote:
> Basil L. Contovounesios wrote:
>> Isn't this saying that C23 [[reproducible]] is stricter than GCC pure?
>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2956.htm#some-differences-with-gcc-const-and-pure
> Yes: [1], section "Note on GCC attributes"
On mingw and MSVC, the replacement code from lib/flock.c is working fine.
No test failure here.
2024-06-03 Bruno Haible
flock tests: Don't expect a failure on native Windows.
* modules/flock-tests (Depends-on): Add test-xfail.
(Makefile.am): Don't augment XFAIL_TESTS o
Hi Ken,
> > In this situation, the "trivial" ACL is not
> > user::rwx
> > group::r-x
> > other::r-x
> > but instead
> > user::rwx
> > group::r-x
> > group:SYSTEM:rwx
> > group:Administrators:rwx
> >
Hi Bruno,
On 6/3/2024 11:28 AM, Bruno Haible wrote:
On the GitHub CI machines for Cygwin, I'm seeing this test failure:
FAIL: test-file-has-acl-2.sh
file_has_acl("tmpfile0") returned yes, expected no
FAIL test-file-has-acl-2.sh (exit status: 1)
The cau
While the nstrftime, c-nstrftime tests now work in my Windows 10 machine,
they still fail on the GitHub Windows 10 machines:
CET-1CEST,M3.5.0,M10.5.0/3: expected "1970-01-01 01:00:00 +0100 (CET)", got
"1970-01-01 00:00:00 + (Coordinated Universal Time)"
CET-1CEST,M3.5.0,M10.5.0/3: expected "1
* lib/attribute.h: Update comments to better reflect what
GCC actually does with pure and const functions.
---
ChangeLog | 6 +
lib/attribute.h | 64 +
2 files changed, 44 insertions(+), 26 deletions(-)
diff --git a/ChangeLog b/ChangeLog
On the GitHub CI machines for Cygwin, I'm seeing this test failure:
FAIL: test-file-has-acl-2.sh
file_has_acl("tmpfile0") returned yes, expected no
FAIL test-file-has-acl-2.sh (exit status: 1)
The cause is that in this situation, the current directory is not
Collin Funk wrote:
> Good point. I've pushed this patch adding a set() around that one call.
Thanks.
> This comment is interesting:
>
> # We need NO_EXPENSIVE_WARN_CFLAGS, because with gcc 13, the compilation of
> # libxml/parser.c requires 1.9 GB of RAM with -fanalyzer, as opposed to
> #
On the GitHub CI macOS machines (each of macOS 11, 12, 13, 14), I
occasionally see the test-dprintf-posix2.sh test fail.
This patch will skip this test instead on macOS, like we already
do with the test-fprintf-posix3.sh test.
2024-06-03 Bruno Haible
dprintf-posix tests: Skip the mem
Bruno Haible writes:
>> The lists there seem small enough that I doubt it matters too much.
>
> Bad excuse :) You haven't seen this module yet:
> https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gnulib-local/modules/libxml;h=dc6404c59362e5d17885a211a61a4eed99da6642;hb=HEAD#l130
Hahaha
Hi Collin,
> Oops yes. Good point, I must have overlooked that. It appears that it
> will be O(n²). In this loop [1] and the else branch of
> "PyAnySet_Check(other)" [2].
Thanks for checking.
> The lists there seem small enough that I doubt it matters too much.
Bad excuse :) You haven't seen th
Hi Bruno,
Bruno Haible writes:
> The variable mentioned_files in pygnulib/GLModuleSystem.py line 599
> was a set and is now a list. Is the expression
> lib_files.difference(mentioned_files)
> therefore being evaluated more slowly (as O(n²) where it was O(n) before)?
> That is, does Python iter
Some tests use HAVE_DECL_ALARM without testing for 'alarm' first.
This patch fixes it.
2024-06-03 Bruno Haible
pthread-* tests, regex tests: Prepare for use of 'alarm'.
* modules/pthread-cond-tests (configure.ac): Test whether 'alarm' is
declared.
* modules/pt
The mtx tests use atomic-int-isoc.h, which uses . It therefore
needs this patch:
2024-06-03 Bruno Haible
mtx tests: Fix a possible link error.
* modules/mtx-tests (Files): Add m4/semaphore.m4.
(configure.ac): Require gl_SEMAPHORE.
(Makefile.am): Link test-mtx w
In the CI for grep and sed [1][2], I'm seeing this build error:
...
CC test-pthread-mutex.o
CCLD test-pthread-mutex
/usr/bin/ld: cannot find @LIB_SEMAPHORE@: No such file or directory
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:5613: test-pthread-mutex] Error 1
Hi Collin,
> Indirectly this also fixes two issues. The first is the same issue as
> yesterdays patch. Variables with a trailing comment, e.g.
>
> lib_SOURCES += file.c file.h # comment
>
> are not matched. As far as I can tell none of the module descriptions
> have this comment style but gn
Gnulib's ieee754.h defines __LITTLE_ENDIAN and __BIG_ENDIAN, which are
redundantly defined in another header in this release of the NDK, to
wit, sys/endian.h, and conflicts with this definition when both are
included by the same unit. Attached is one example of a warning message
reporting such a c
24 matches
Mail list logo
