[PATCH 2/3] totalorder: speed up configuration

deletions(-) diff --git a/ChangeLog b/ChangeLog index bf205bd23f..3ace239450 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,10 @@ 2023-10-05 Paul Eggert + totalorder: speed up configuration + * m4/totalorder.m4 (gl_FUNC_TOTALORDERF, gl_FUNC_TOTALORDER) + (gl_FUNC_TOTALORDERL

[PATCH 1/3] totalorderl: minor porting fixes

+- 2 files changed, 28 insertions(+), 17 deletions(-) diff --git a/ChangeLog b/ChangeLog index 31e02bbf4a..bf205bd23f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2023-10-05 Paul Eggert + + totalorderl: minor porting fixes + * lib/totalorderl.c (LDBL_SIGNBIT_WORD

[PATCH 3/3] isnan: slightly simplify configuration

insertions(+), 9 deletions(-) diff --git a/ChangeLog b/ChangeLog index 3ace239450..f09de5233e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,11 @@ 2023-10-05 Paul Eggert + isnan: slightly simplify configuration + * m4/isnand.m4 (gl_FUNC_ISNAND): + * m4/isnanf.m4 (gl_FUNC_ISNANF

[PATCH] totalorder, totalorderf, totalorderl: new modules

/ChangeLog +++ b/ChangeLog @@ -1,3 +1,18 @@ +2023-10-01 Paul Eggert + + totalorder, totalorderf, totalorderl: new modules + * lib/math.in.h: Declare totalorderf, totalorder, totalorderl. + * lib/totalorder.c, lib/totalorderf.c, lib/totalorderl.c: + * m4/totalorder.m4, modules

Re: Remaining support for GNULIB_MCEL_PREFER

Ouch, I thought I had tested all the affected modules, both with and without mcel-prefer. Evidently not. Thanks for reporting that. I installed the attached.From 49a9f86340d4a226c82b708e01d9a178d4ae77ce Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 30 Sep 2023 18:03:48 -0700 Subject

[PATCH] mbscasestr: support GNULIB_MCEL_PREFER

+++-- lib/mbsstr.c | 8 +-- modules/mbscasestr | 1 + 4 files changed, 174 insertions(+), 9 deletions(-) diff --git a/ChangeLog b/ChangeLog index 39b043775f..7b7246f2a5 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,17 @@ +2023-09-25 Paul Eggert + + mbscasestr: support GNULIB_M

[PATCH] mbschr, mbsrchr: support GNULIB_MCEL_PREFER

/mbsrchr.c | 18 +- 3 files changed, 41 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 160332c116..4430828d3b 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,12 @@ 2023-09-21 Paul Eggert + mbschr, mbsrchr: support GNULIB_MCEL_PREFER

Re: ./lib/error.h:410:8: warning: ISO C forbids braced-groups within expressions [-Wpedantic]

by installing the attached patch. Please give it a try. Even if -Wpedantic has problems, it's better if Gnulib doesn't override the builder unnecessarily. From 18bf1bf18be99e59624f039220feb19355fe239f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 21 Sep 2023 14:26:24 -0700 Subje

[PATCH] crypto/sm3: rename gl_cv_* variable for clarity

--- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2023-09-21 Paul Eggert + + crypto/sm3: rename gl_cv_* variable for clarity + * m4/gc-sm3.m4 (gl_cv_libgcrypt_md_sm3): + Rename from gl_cv_libcrypt_md_sm3 since this is unrelated to libcrypt. + 2023-09-17 Paul Eggert

Re: [PATCH v7 12/13] ext4: switch to multigrain timestamps

On 2023-09-19 09:31, Jeff Layton wrote: The typical case for make timestamp comparisons is comparing source files vs. a build target. If those are being written nearly simultaneously, then that could be an issue, but is that a typical behavior? I vaguely remember running into problems with 'mak

[PATCH] intprops: pacify GCC -Wtype-limits

..49ee4e6dd1 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2023-09-17 Paul Eggert + + intprops: pacify GCC -Wtype-limits + * lib/intprops-internal.h: Pacify gcc (GCC) 13.2.1 20230728 (Red + Hat 13.2.1-1) x86-64 -Wtype-limits on bleeding-edge diffutils. + 2023-09-16 Bruno

Re: readutmp backlog

On 9/10/23 11:27, Thorsten Kukuk wrote: So from my view, I currently don't see something better than wtmpdb and I don't see anybody working on a different solution. Thanks for the heads-up. I now also see that the latest Linux-PAM release (1.5.3) deprecated pam_lastlog and has suggested using

[PATCH 2/4] mbsstr: support GNULIB_MCEL_PREFER

ions(+), 4 deletions(-) diff --git a/ChangeLog b/ChangeLog index fe2864b0ee..a97a5081b0 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,16 @@ 2023-09-09 Paul Eggert + mbsstr: support GNULIB_MCEL_PREFER + Support mcel API for apps that prefer it. + * lib/mbsstr.c [GNULIB_M

[PATCH 1/4] mbslen: support GNULIB_MCEL_PREFER

(-) diff --git a/ChangeLog b/ChangeLog index 5929236789..fe2864b0ee 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,11 @@ 2023-09-09 Paul Eggert + mbslen: support GNULIB_MCEL_PREFER + Support mcel API for apps that prefer it. + The following changes are in effect only if

[PATCH 0/4] mcel-prefer patches for grep

This patch series is so that GNU grep can prefer mcel uniformly. Paul Eggert (4): mbslen: support GNULIB_MCEL_PREFER mbsstr: support GNULIB_MCEL_PREFER trim: support GNULIB_MCEL_PREFER propername: support GNULIB_MCEL_PREFER ChangeLog | 31 ++ lib/mbslen.c | 11

[PATCH 4/4] propername: support GNULIB_MCEL_PREFER

+++ lib/propername.c | 36 ++-- modules/propername | 1 + 3 files changed, 42 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 2b0569af8b..a01e01a657 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,12 @@ 2023-09-09 Paul Eggert

[PATCH 3/4] trim: support GNULIB_MCEL_PREFER

+++-- modules/trim | 1 + 3 files changed, 35 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index a97a5081b0..2b0569af8b 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,12 @@ 2023-09-09 Paul Eggert + trim: support GNULIB_MCEL_PREFER + Support mcel

Re: i18n backlog

On 2023-09-09 07:58, Bruno Haible wrote: Currently the mbscasecmp tests test only valid input. Someone should extend the unit test to cover strings with invalid input bytes. Then we could see what difference exactly it makes. If I recall our earlier discussion correctly, when given inv

documentation for SEE vs MEE etc.

On 2023-09-09 07:58, Bruno Haible wrote: * Commit b93de66735cd6f935ee0970f8cb26908d113e09d introduced mcel.h. Summarize, in comments, the discussion we had regarding SEE and MEE. Basically, MEE is good in all circumstances, whereas SEE is only good if the surrounding applications does on

untabifying mcel.h, mountlist.c, verify.h

.From 17ca38df4fbdba1cc0644583534e8c00958106a8 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 9 Sep 2023 10:13:50 -0700 Subject: [PATCH] Remove tabs from mcel.h, mountlist.h, verify.h --- lib/mcel.h | 16 lib/mountlist.c | 6 +++--- lib/verify.h| 10 +- 3 files changed, 16 inser

Re: chown and chgrp won't change on systems without sys_lchown()

On 2023-09-09 07:50, Jordi Sanfeliu wrote: Your patch did work successfully. :-) Thanks, I installed it into Gnulib.

trim.c mbiterf vs mbuiterf

On 2023-09-09 07:58, Bruno Haible wrote: * Commit 5f27affb42337dc605a9a59f1c6a99516cd9747a has replaced a use of mbiterf.h with mbuiterf.h. I'm not convinced this provides a speed improvement, since the comments in mbuiterf.h say: The mbuif_* macros are therefore suitable when there i

Re: readutmp backlog

On 2023-09-09 04:13, Bruno Haible wrote: What's the right replacement? - wtmpdb ? [3] - journalctl --list-boots ? [4][5] - last ? [4] This depends on what platforms using systemd will do (if anything) about the information currently stored in /var/log/wtmp on GNU/Linux. As I und

Re: chown and chgrp won't change on systems without sys_lchown()

y, just for fun I wrote the attached patch. Does it fix the original problem for you? I have not installed it into Gnulib because I lack easy access to oddball operating systems that have that particular chown bug. From fa893bf7902889a4375392a0f5a1f0e64e6592dc Mon Sep 17 00:00:00 2001 From: Paul E

Re: mbcel module for Gnulib?, incomplete multibyte sequences

On 2023-08-07 00:32, Paul Eggert wrote: I'll think about naming. It's been a month and I couldn't think of anything better than to shorten the name from mbcel to mcel, so I did that and installed the attached patches. These patches shouldn't affect behavior; that is, t

Re: nullptr vs NULL

On 2023-09-04 18:04, Bruno Haible wrote: It's still a bit early to do so, because it can trigger compilation errors when people are not super careful Doesn't Gnulib's nullptr module fix the problems, whatever they are? (The URL you gave needs a GitHub login to view, which is a bit unfriendly.)

Re: argp: Distinguish NULL and '\0' from 0

On 2023-09-04 15:44, Bruno Haible wrote: - fs = 0; + fs = NULL; This use of 0 probably dates back to when the GNU Coding Standards said, in effect "Don't bother changing 0 to NULL when it doesn't affect semantics." I've been gradually switching code to use nullptr instead

Re: -Wextra ?

On 2023-09-04 03:07, Bruno Haible wrote: Is that use of -Wextra an experiment, or do you want to use it always? Oh, it was just an experiment. I'm asking because some the warnings that it enables are undesired, IMO, Quite right. I expect that many of the warnings you found are false alarm

[PATCH] same-inode, stat-size: support pointers too

changed, 288 insertions(+), 150 deletions(-) create mode 100644 lib/same-inode.c diff --git a/ChangeLog b/ChangeLog index 4273e680ec..601ab4f2c0 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,60 @@ +2023-09-03 Paul Eggert + + same-inode, stat-size: support pointers too + Add

[PATCH] Warn about Bug#65599 with CIFS chmod/chown

--- doc/posix-functions/chmod.texi| 6 ++ doc/posix-functions/chown.texi| 6 ++ doc/posix-functions/fchmod.texi | 6 ++ doc/posix-functions/fchmodat.texi | 7 +++ doc/posix-functions/fchown.texi | 6 ++ doc/posix-functions/fchownat.texi | 6 ++ doc/posix-functio

Re: Possible bug in qcopy-acl.c

On 2023-09-01 11:47, Ondrej Valousek wrote: If it returns 1, then we probably don't care about few more syscalls because in most cases we copy files w/o acls. I think I'd care about unnecessary syscalls if I were using a filesystem with ACLs.

Re: Possible bug in qcopy-acl.c

On 2023-09-01 04:24, Ondrej Valousek wrote: The disadvantage of it would be the additional call for file-has-acl() so hence few more kernel calls. Can the extra syscalls be avoided by migrating/copying some of file-has-acl.c's functionality into qcopy-acl.c? The idea would be to invoke listx

Re: bug#65617: coreutils 9.4: seg.fault in readutmp with systemd

Thanks for reporting that. I installed the attached patch into Gnulib and this should appear in the next coreutils release.From 1e6a26f9312bb47e070f94b17b14dc1a6ffbb74f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 30 Aug 2023 18:26:52 -0700 Subject: [PATCH] readutmp: fix core dump if

[PATCH] wchar-single: fix module broken since 2021

-single | 4 2 files changed, 12 insertions(+) diff --git a/ChangeLog b/ChangeLog index a839600839..702f195ec0 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2023-08-30 Paul Eggert + + wchar-single: fix module broken since 2021 + Adjust to 2021-03-07 change “Rename

Re: spelling fix: cloneable -> clonable

e,' on the other hand, is the correct spelling and is widely accepted in both British and American English." (!) In this particular context the word doesn't add enough useful info to be worth the spelling discordance, so I removed it by installing the attached.From fbdc9a0724f5037ba0f

[PATCH] rename: fix m4 comment

* m4/rename.m4: Fix comment to match code. --- m4/rename.m4 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/m4/rename.m4 b/m4/rename.m4 index b41c3f3ac6..096f088cc6 100644 --- a/m4/rename.m4 +++ b/m4/rename.m4 @@ -1,4 +1,4 @@ -# serial 35 +# serial 36 # Copyright (C) 2

[PATCH 1/3] Tune single-byte code involving tolower

+- lib/mbspcasecmp.c | 47 +--- 6 files changed, 109 insertions(+), 103 deletions(-) diff --git a/ChangeLog b/ChangeLog index ff09eed9ba..de52b57755 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,15 @@ +2023-08-26 Paul

[PATCH 3/3] trim: do not over-allocate result

--git a/ChangeLog b/ChangeLog index 64db236853..5c858366d5 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,15 @@ +2023-08-26 Paul Eggert + + trim: do not over-allocate result + * lib/trim.c: Include mbuiterf.h, not mbiterf.h, since we no + longer compute strlen at first

[PATCH 2/3] propername: tune single-byte code

index de52b57755..64db236853 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2023-08-26 Paul Eggert + + propername: tune single-byte code + * lib/propername.c (mbsstr_trimmed_wordbounded): Cache MB_CUR_MAX. + Simplify word boundary detection in single-byte code. + 2023-08

[PATCH] exclude: refactor for more-modern style

+1,27 @@ +2023-08-24 Paul Eggert + + exclude: refactor for more-modern style + * lib/exclude.c: Sort include directives. + (fnmatch_pattern_has_wildcards, file_name_matches): + Prefer ‘true’ to ‘1’. + (string_hasher, string_compare, string_compare_ci): + Avoid

Re: master 349798a9b8: Demote errors from utimensat copying directories

On 2023-08-26 01:22, Po Lu wrote: Given that, I'll resort to disrearding such errors from set-file-times only on the pertinent filesystems instead. Will this be done by extending emacs/src/androidvfs.c to add vops for futimens and utimensat, or by some other means? I'm a bit unclear about the

[PATCH] utimens: update FIXME date

@@ -1,3 +1,9 @@ +2023-08-26 Paul Eggert + + utimens: update FIXME date + * lib/utimens.c (fdutimens): Change FIXME date to agree with + similar FIXME in utimensat.c. + 2023-08-24 Paul Eggert exclude: refactor for more-modern style diff --git a/lib/utimens.c b/lib

[PATCH] exclude: refactor for more-modern style

+1,27 @@ +2023-08-24 Paul Eggert + + exclude: refactor for more-modern style + * lib/exclude.c: Sort include directives. + (fnmatch_pattern_has_wildcards, file_name_matches): + Prefer ‘true’ to ‘1’. + (string_hasher, string_compare, string_compare_ci): + Avoid

Re: M4 assembler error on compile

On 8/17/23 08:57, Eric Blake wrote: m4 is single-threaded, so an asynsafe-spin operation is not going to be vital to performance Gnulib has various options for omitting unnecessary locking code in single-threaded apps. If you have time, you might investigate why that is not happening for GNU

[PATCH] unlocked-io: fix getc_unlocked typo

-08-21 Paul Eggert + + unlocked-io: fix getc_unlocked typo + * lib/unlocked-io.h (getc): Fix misspelling of ‘getc_unlocked’. + 2023-08-21 Bruno Haible alignasof, stdalign: Fix a compilation error in C++ mode on FreeBSD 12. diff --git a/lib/unlocked-io.h b/lib/unlocked

Re: modules alignalloc and propername-lite

On 8/21/23 09:26, Bruno Haible wrote: When I run './check-copyright', I get (among other output) a small list of inconsistencies: Module LicenseFile License File name = = = LGPLv2+ GPL lib/align

Re: ldexpl: Fix signed integer overflow

less efficient since GCC implements N % 2 and N / 2 by masking and shifting. I installed the attached.From 3703c742aa9b90d57bc7427b94cec21a6492d106 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 20 Aug 2023 17:55:03 -0700 Subject: [PATCH] =?UTF-8?q?ldexp:=20port=20to=20non-two=E2=80=99s=2

Re: ldexpl: Fix signed integer overflow

ixed it by installing the attached.From 9c7ca2ba1020fadba5939b3792f1021843c1c808 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 20 Aug 2023 13:23:11 -0700 Subject: [PATCH] ldexp: fix INT_MIN infloop * lib/ldexp.c (FUNC): Instead of converting EXP to unsigned, work on it directly. This s

Re: -Wno-error in CFLAGS for gnulib code?

On 8/17/23 20:07, Bruno Haible wrote: I suggest to add -Wno-error in $(GL_CFLAG_GNULIB_WARNINGS), and thus avoid FTBFS situations if some compiler warnings occur in gnulib code. Sounds good to me, thanks.

Re: boot-time: straighten code

On 2023-08-14 06:51, Bruno Haible wrote: But that is just a workaround. Is someone among the glibc people looking at the original glibc bughttps://sourceware.org/bugzilla/show_bug.cgi?id=30701 ? As far as I know, nobody is looking into it other than you and me. I think it's low priority as pe

[PATCH 2/2] fts: improve memory-allocation errno handling

. --- ChangeLog | 8 lib/fts.c | 12 ++-- modules/fts | 4 3 files changed, 18 insertions(+), 6 deletions(-) diff --git a/ChangeLog b/ChangeLog index 3a03afaea1..ae6a1b08f4 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,13 @@ 2023-08-13 Paul Eggert + fts: improve

[PATCH 1/2] hash: set errno on failure

/ChangeLog @@ -1,3 +1,13 @@ +2023-08-13 Paul Eggert + + hash: set errno on failure + * lib/hash.c: Include errno.h. + (compute_bucket_size, hash_initialize, hash_rehash) + (hash_insert_if_absent): Set errno reliably on failure. + (hash_free): Preserve errno, like p

Re: boot-time: straighten code

ve tested it only on Ubuntu 23.04. If this patch works we can propagate it to Gnulib.From d2db6d8e92282de8ffb5293dd1445e3a2e549ed0 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 12 Aug 2023 23:20:12 -0700 Subject: [PATCH] Temp patch for Android --- configure.ac| 19 --

Re: boot-time: straighten code

nk's contents should be the boot time. These symlinks are Emacs's only use of boot time.From 5e736ca6ccfa131736ab0b3a298de2cb319e7dfb Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 12 Aug 2023 19:39:11 -0700 Subject: [PATCH] Improve boot-time gathering MIME-Version: 1.0 Content-T

Re: readutmp, boot-time: Fix parsing of /proc/uptime

Thanks for catching that. Emacs would likely prefer not having to depend on c-strtod so I installed the attached further patch.From 5528e726e9cc1ff9a2c7a71100450c52b65e9e7f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 12 Aug 2023 16:54:51 -0700 Subject: [PATCH] boot-time,readutmp: do

[PATCH] boot-time,readutmp: remove -lrt usage

| 4 +--- modules/boot-time | 1 - 3 files changed, 8 insertions(+), 4 deletions(-) diff --git a/ChangeLog b/ChangeLog index 407e1733ca..9e5c65f564 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,12 @@ 2023-08-12 Paul Eggert + boot-time,readutmp: remove -lrt usage + This code

[PATCH] boot-time,readutmp: do not depend on fopen-gnu

@ 2023-08-12 Paul Eggert + boot-time,readutmp: do not depend on fopen-gnu + These modules should work well enough even if fopen is not fixed + to conform to fopen-gnu standards. The only gotcha I can see is + older fopen implementations that lack support for "e&

[PATCH] readutmp: do not depend on timespec_get

@@ -1,5 +1,9 @@ 2023-08-12 Paul Eggert + readutmp: do not depend on timespec_get + boot-time code no longer needs it. + * modules/readutmp (Depends-on): Remove timespec_get. + boot-time: do not depend on timespec_get This is for Emacs, which does not use

[PATCH] boot-time: do not depend on timespec_get

-08-12 Paul Eggert + + boot-time: do not depend on timespec_get + This is for Emacs, which does not use timespec_get now + and which likes to minimize dependencies. + Also, treat musl libc like recent glibc, + and fix a timespec_get return value typo. + * lib

[PATCH] c-file-type: new module

(-) create mode 100644 lib/c-file-type.c create mode 100644 modules/c-file-type diff --git a/ChangeLog b/ChangeLog index 31aec050a8..d407d7b4c6 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,13 @@ +2023-08-12 Paul Eggert + + c-file-type: new module + * lib/c-file-type.c: New file

Re: boot time on Linux

On 2023-08-09 19:14, Po Lu wrote: This uses the uptime counter (which also results in an SELinux denial for me, but different Android distributions have SELinux policies of varying strictness), which cannot establish the precise time the system started Emacs doesn't need a precise boot time. Al

Re: boot time on Linux

o Lu, the main developer for Emacs on Android.From cc0a30a876adffa5ec110df9f4e0f21097f6d73e Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 9 Aug 2023 12:06:25 -0700 Subject: [PATCH] Adjust to random-seed move For some time, GNU/Linux systems have put their random-seed file somewhere other

Re: bug#64937: "who" reports funny dates

Thanks, I installed the attached to simplify a bit further. A nice consequence of these recent changes is that we get to remove some pragmas. The first patch is for Gnulib; the other two are for Coreutils.From e14d7e198f96039dbc4fb2118739e6ca1fc4cec6 Mon Sep 17 00:00:00 2001 From: Paul Eggert

Re: bug#64937: "who" reports funny dates

On 2023-08-08 05:24, Thorsten Kukuk wrote: Something emacs needs to get fixed. On musl libc systems like Alpine, you don't have utmp nor wtmp. Yes, as Bruno mentioned, we know of no way to find the boot time on Alpine. When Emacs cannot determine the boot time, it pretends that the system bo

Re: bug#64937: "who" reports funny dates

On 2023-08-07 04:22, Bruno Haible wrote: Since the fact that /var/run/utmp and /var/log/wtmp are world-readable implies that they are world-lockable and thus the DoS bug https://sourceware.org/bugzilla/show_bug.cgi?id=24492 applies, to me it's clear that both utmp and wtmp needs to go away Alt

[PATCH] quotearg: fix obsolete comment

* lib/quotearg.h: Fix comment to match behavior. This fixes a commentary bug introduced in commit 1a43a982c927eaf26bbc2701a872009d9be4b33b "quotearg: do not use grave accent for left quote" dated 2011-12-18 15:44:17+01, where the comment was not updated to match the changed behavior. --- lib/quote

Re: mbcel module for Gnulib?, incomplete multibyte sequences

some sense, the choice between SEE and MEE is orthogonal to the choice between mbcel and mbiter, as it'd be easy to modify mbcel to optionally support MEE and also easy to modify mbiter to optionally support SEE. From 9802e8bde49985f5fd8824fd8d03a354096092fc Mon Sep 17 00:00:00 2001 From: Paul E

Re: bug#64937: "who" reports funny dates

On 2023-08-06 14:06, Thorsten Kukuk wrote: SysV Init is gone and the majority does not miss it, and I don't see a reason why "who /var/log/wtmp" needs to stay. I don't want to get into the middle of another systemd vs init battle. But I don't see why this is relevant to that battle. Fedora 38

Re: bug#64937: "who" reports funny dates

On 2023-08-06 14:10, Thorsten Kukuk wrote: On Sun, Aug 06, Paul Eggert wrote: On 2023-08-06 13:00, Paul Eggert wrote: How does "last" emulate /var/log/wtmp using systemd? Oh, I see from <https://github.com/thkukuk/wtmpdb> that wtmpdb comes with its own "last". I

Re: bug#64937: "who" reports funny dates

On 2023-08-06 13:00, Paul Eggert wrote: How does "last" emulate /var/log/wtmp using systemd? Oh, I see from <https://github.com/thkukuk/wtmpdb> that wtmpdb comes with its own "last". Is the plan to migrate this code into util-linux "last", or simply to ki

Re: bug#64937: "who" reports funny dates

On 2023-08-03 23:53, Thorsten Kukuk wrote: And yes, "who /var/log/wtmp" will not work with this, too. But is this really a required or usefull use case? /usr/bin/last can give you the same output. Sure, but some people use "who" for that.[1][2][3] This is partly because "who" predates "last".

Re: bug#64937: "who" reports funny dates

. I installed the attached to Gnulib.From dcf286c586069684fe4d5bb2bd770394cd7cdad6 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 6 Aug 2023 12:43:05 -0700 Subject: [PATCH] readutmp: fix comment bug ID * lib/readutmp.c: Fix comment (thanks to Bruno Haible). --- lib/readutmp.c | 2 +- 1

Re: bug#64937: "who" reports funny dates

On 2023-08-04 05:52, Bruno Haible wrote: This code is meant to be multithread-safe. Thanks for fixing that, I hadn't realized it was supposed to be thread-safe (thread-safety is not needed for Coreutils). Making the variables volatile is a win for multithreaded apps. Although the resulting

[PATCH] Document Android, OpenBSD printf "%n" lack

In doc/posix/functions/*printf*.texi, document that the POSIX-specified printf functions do not support the %n format on Android and OpenBSD. This lack of support is deliberate, as %n is a common target of attacks on security. --- doc/posix-functions/dprintf.texi | 2 +- doc/posix-functions/fpri

Re: printf and INT_MAX

On 2023-08-04 02:31, Bruno Haible wrote: In coreutils, Paul Eggert did: Don’t use printf if the output might in theory be longer than INT_MAX. It sounds like I should put the planned printf-without-INT_MAX-limitation changes [1] higher on my priority list... Bruno [1] https://lists.gnu.org

Re: utmp 64 bit time_t support

as an idea for fixing glibc bug 30701.From 0a7a71a4f24b4608662b4532bd17aef758f049fd Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 5 Aug 2023 11:16:12 -0700 Subject: [PATCH] readutmp: anticipate Y2038 hack for utmp * lib/readutmp.c (struct utmpx32): Use unsigned int for tv_sec, not int, as th

[PATCH] diffseq: simplify lint removal

+--- 2 files changed, 14 insertions(+), 19 deletions(-) diff --git a/ChangeLog b/ChangeLog index a6b3a10da2..e1437b1b41 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2023-08-05 Paul Eggert + + diffseq: simplify lint removal + * lib/diffseq.h (IF_LINT): Remove

Re: bug#64937: "who" reports funny dates

what I had. So I nstalled the first ten attached patches into Gnulib, and the last patch into coreutils. I haven't tested this with the latest systemd so there could well be typos in that part of the code.From 39a4cb0afdf4f2a1e6c2f3176b84e5b4cfe8996d Mon Sep 17 00:00:00 2001 From: Paul Eggert

Re: bug#64954: GNU 'uptime' on OpenBSD always prints "0 users"

Thanks, I propagated that into Coreutils and installed the simplified patch I mentioned yesterday. Closing the coreutils bug report.

Re: bug#64937: "who" reports funny dates

On 2023-07-31 00:08, Thorsten Kukuk wrote: 1. you need to extend ut_tv from 32bit time_t to 64bit time_t, or your patch will not survive 2038. Yes, that's the plan. Gnulib's readutmp module already does this, in apps that also use the year2038 or year2038-recommended modules (which most do).

Re: [PATCH] readutmp: work around glibc utmpx bug

On 2023-07-30 06:23, Bruno Haible wrote: Should this be reported in the glibc bug tracker? I see an open bug https://sourceware.org/bugzilla/show_bug.cgi?id=28146 but it does not seem to be worked on currently. I reported it here: https://sourceware.org/bugzilla/show_bug.cgi?id=30701 It may b

Re: bug#64937: "who" reports funny dates

On 2023-07-30 04:02, Pádraig Brady wrote: Yes I think the consensus is to switch away from the utmp API, which was recently discussed at: https://lists.gnu.org/archive/html/coreutils/2023-06/msg00024.html If I understand that discussion correctly, the idea is to switch from utmp/utmpx to the s

[PATCH] readutmp: work around glibc utmpx bug

ngeLog @@ -1,3 +1,13 @@ +2023-07-29 Paul Eggert + + readutmp: work around glibc utmpx bug + When compiled with _TIME_BITS=64, glibc does not work, + because the files use 32-bit time_t and the code passes this to + the user unmodified, but defines a struct with

Re: timespec_get: port to Ubuntu 23.04

On 2023-07-28 08:06, Bruno Haible wrote: Do you remember how the user was supposed to determine which modules from time.in.h he needs to import? How did the GNULIB_PORTCHECK macro help doing that (or was supposed to help doing that)? This is all old history and I had to look into the archives t

Re: mbcel module for Gnulib?, incomplete multibyte sequences

On 2023-07-27 12:19, Paul Eggert wrote:  --- a/lib/mbcel.h  +++ b/lib/mbcel.h  @@ -191,3 +191,3 @@ mbcel_scan (char const *p, char const *lim)     if (_GL_UNLIKELY ((size_t) -1 / 2 < len))  -    return (mbcel_t) { .err = *p, .len = 1 };  +    return (mbcel_t) { .err = *p, .len =

Re: timespec_get: port to Ubuntu 23.04

On 2023-07-24 01:58, Bruno Haible wrote: Is something wrong with the m4/time_h.m4 idioms? What was the recipe to reproduce a bug here? Here's a recipe: git clone https://git.savannah.gnu.org/git/diffutils.git cd diffutils git checkout 25594ef0d9cda37835499e637a8ec35126aecf72 ./bootstr

Re: mbcel module for Gnulib?, incomplete multibyte sequences

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 <https://www.gnu.

Re: mbcel module for Gnulib?, incomplete multibyte sequences

On 2023-07-21 16:25, Paul Eggert wrote: Even mbcel strains GCC's capabilities to optimize. When I look at the x86-64 code it generates I see clear opportunities for tighter code. If I have time I'll fire off a suggestion or two to the GCC maintainers. With luck these suggestions

Re: mbcel module for Gnulib?, incomplete multibyte sequences

On 2023-07-24 17:34, Bruno Haible wrote: Paul Eggert wrote: It gets this info from mbrtoc32, which on most platforms gets this info from mbrtowc. This multibyte scanner knows when the bytes it has seen so far constitute - a complete character, or - an invalid character, or - an

Re: mbcel module for Gnulib?, incomplete multibyte sequences

On 2023-07-24 15:58, Bruno Haible wrote: Paul Eggert wrote: in UTF-8 the byte sequence E0 80 is not an incomplete character (in the sense that additional bytes may lead to a complete character), because every byte you append to E0 80 causes glibc mbrtoc32 to return (size_t) -1. Yet glibc

Re: mbcel module for Gnulib?, incomplete multibyte sequences

On 2023-07-21 17:33, Bruno Haible wrote: It gets this info from mbrtoc32, which on most platforms gets this info from mbrtowc. This multibyte scanner knows when the bytes it has seen so far constitute - a complete character, or - an invalid character, or - an incomplete character (i.e. i

Re: mbcel module for Gnulib?, incomplete multibyte sequences

On 2023-07-21 17:33, Bruno Haible wrote: It gets this info from mbrtoc32, which on most platforms gets this info from mbrtowc. This multibyte scanner knows when the bytes it has seen so far constitute - a complete character, or - an invalid character, or - an incomplete character (i.e. i

Re: mbcel module for Gnulib?, incomplete multibyte sequences

h is dubious) I don't see see how it generalizes to non-UTF-8 multi-byte encodings. Admittedly these encodings are less important. I had even considered dropping support for them in GNU diff, as that would simplify maintenance and improve performance. However, that might be a bridge too f

Re: [PATCH 2/2] Document POSIX obsolescence

On 2023-07-19 16:39, Bruno Haible wrote: It's good that you have access to this draft. I don't (paywall). I didn't pay, unless one counts reviewing as a form of payment. Unfortunately I do not have time to review more than little dribs and drabs. The draft is getting fairly large. I signed

[PATCH 2/2] Document POSIX obsolescence

/ulimit.texi | 3 +++ doc/posix-functions/utime.texi| 3 +++ 33 files changed, 122 insertions(+), 4 deletions(-) diff --git a/ChangeLog b/ChangeLog index 6a4d92d218..ec8cd5261d 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,27 @@ +2023-07-19 Paul Eggert

[PATCH 1/2] Don’t worry about Version 7 tolower

/strncasecmp.c | 6 ++ 10 files changed, 35 insertions(+), 39 deletions(-) diff --git a/ChangeLog b/ChangeLog index ba8fc38e8a..6a4d92d218 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,17 @@ +2023-07-19 Paul Eggert + + Don’t worry about Version 7 tolower + Some code ported back to pre

[PATCH] mbiterf, mbuiterf: port to strict C17

(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 6b0079d8d0..393da435f7 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2023-07-18 Paul Eggert + + mbiterf, mbuiterf: port to strict C17 + I ran into this problem on NetBSD 9.3. + * lib/mbiterf.h (mbiterf_next

Re: From wchar_t to char32_t, new module mbszero

ourse.) One thing I noticed on NetBSD 9.3 x86-64 (it has GCC 7), is that it didn't optimize memset calls away. So in memcel.h I stuck with initializing by hand rather than using memset. From c640bec4f3df010b47dae930ea13d997f0026f9b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 18 J

Re: mbcel module for Gnulib?, incomplete multibyte sequences

On 2023-07-16 15:18, Bruno Haible wrote: Paul Eggert wrote: Although I'm sure mbiter can be improved I don't see how it could catch up to mbcel so long as it continues to solve a harder problem than mbcel solves. I don't know exactly what you mean by "harder problem".

Re: From wchar_t to char32_t, new module mbszero

On 2023-07-16 01:43, Bruno Haible wrote: Paul Eggert wrote: However, after implementing mbszero with this data and enabling its use in many places, I got test failures on NetBSD and Solaris. - On NetBSD, the minimum we need to clear is 28 bytes. - On Solaris OmniOS and OpenIndiana, the

<    1   2   3   4   5   6   7   8   9   10   >