On 2025-09-08 10:05, Michael Figiel via GNU coreutils Bug Reports wrote:
The expected behaviour is on FreeBSD and OpenBSD, so different code
base, but I think it's more consistent with the POSIX description of
expr.
My reading of POSIX is that the GNU behavior is required and the Fr
Sergei Trofimovich writes:
>> > > This is a kernel bug in macOS. Can you report it or otherwise
>> > > arrange to have the kernel bug fixed? I expect that you have
>> > > better connections with Apple than I do. A proposed patch
>> > > (relat
am confident it will fix the
others. Closing this bug report.
Collin
>From 24fb014092ba8d831c25cd8757a6a738927bb743 Mon Sep 17 00:00:00 2001
Message-ID: <24fb014092ba8d831c25cd8757a6a738927bb743.1757040561.git.collin.fu...@gmail.com>
From: Collin Funk
Date: Thu, 4 Sep 2025 19:30:00
e number,
> > > which is what we want. So that's not indicating any problem.
> > >
> > >
> > > Oh, I see the problem now. For a socket or pipe, macOS fstat
> > > returns the full 64-bit inode number, whereas macOS stat returns
> > > only
ze field, and a unique device and inode
> > > number.
> >
> > The BUGS note simply means that a pipe has a unique inode number, which
> > is what we want. So that's not indicating any problem.
> >
> >
> > Oh, I see the problem now. For a socket o
Bruno Haible writes:
>> P.S. I actually just noticed this unchanged hunk in my diff:
>>
>> $ git ls-files | grep -E '\.[ch]' | xargs grep -F 'isw'
>> src/wc.c: in_word2 = (! iswspace (wide_char)
>>
>> Okay to change this one to the c32 variant?
>
> Yes. Since 'wide_char' is
Collin Funk wrote:
> I pushed the attached patch. Tested
> in an alpine container, but I am confident it will fix the
> others.
Confirmed: The CI builds on Alpine Linux, macOS 15, FreeBSD 15 succeed now.
Bruno
ith a fold-nbsp
failure (bug #79300), not a fold-spaces failure.
As of today, the failures on macOS 13 and 14 are fixed. The failures on
- Alpine Linux,
- macOS 15,
- FreeBSD 14
are still present in today's CI run.
Yep, I was planning on fixing this one next. So them failing is
exp
Hi Collin,
> Pushed the attatched two patches. The second fixes a 'make syntax-check'
> failure. Will close this bug now.
Thanks. I confirm (via today's CI run) that bug #79300 is fixed.
> P.S. I actually just noticed this unchanged hunk in my diff:
>
> $
Bruno Haible writes:
> On 2025-08-24 I wrote:
>> Today's CI reports a test failure
>> FAIL: tests/fold/fold-spaces
>> on several systems:
>> - Alpine Linux,
>> - macOS 13..15,
>> - FreeBSD 14.
>
> Sorry for the incorrect reporting: macO
Hi,
On 2025-08-24 I wrote:
> Today's CI reports a test failure
> FAIL: tests/fold/fold-spaces
> on several systems:
> - Alpine Linux,
> - macOS 13..15,
> - FreeBSD 14.
Sorry for the incorrect reporting: macOS 13 and 14 failed with a fold-nbsp
failure (bug #79
but name it maybe_c32isnbspace(). Since I
don't want the function to be misunderstood as a wchar_t function.
Pushed the attatched two patches. The second fixes a 'make syntax-check'
failure. Will close this bug now.
Collin
P.S. I actually just noticed this unchanged hunk in my
Thanks, I installed that and am closing the bug report.
Hi,
There was a change today in gnulib, that requires a small change in
packages that use gnulib-tool --with-tests with --makefile-name.
GNU coreutils is one such package.
Currently, './bootstrap' fails like this:
...
autoreconf: running: automake --add-missing --copy --force-missing
gnulib-tests
Closing the bug report.From c6397d08725e651fe81fbbd91df2043674206865 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Mon, 1 Sep 2025 09:55:29 -0700
Subject: [PATCH] df: pacify static analysis
Problem reported by Yubiao Hu <https://bugs.gnu.org/79336>.
* src/df.c (get_dev): Assume MOUNT_P
On 03/09/2025 05:04, Collin Funk wrote:
Pádraig Brady writes:
Thanks, I forgot about that function. That sounds like a good idea
to
me. We can be nice to people who do not use glibc.
We will have to hoist the 'posixly_correct' check out of it before
though. Technically POSIX says that 'fold -s
Pádraig Brady writes:
>> We can improve for the above 2 cases anyway,
>> with something like the attached.
>> Large magnitude negative start values are still problematic.
>
> Ok I pushed that with a test
> included:https://github.com/coreutils/coreutils/commit/701416709
> Marking this as done.
Pádraig Brady writes:
>> Thanks, I forgot about that function. That sounds like a good idea
>> to
>> me. We can be nice to people who do not use glibc.
>> We will have to hoist the 'posixly_correct' check out of it before
>> though. Technically POSIX says that 'fold -s' should only break at
>> c
On 02/09/2025 16:52, Pádraig Brady wrote:
On 02/09/2025 13:11, ondra007@seznam.cz wrote:
It looks like seq for integers bigger than 2^64 sometimes generate wrong
results. There are few examples of wrong output I have found:
$ seq 18446744073709551617 inf | head -3
18446744073709551616
184
On 02/09/2025 13:11, ondra007@seznam.cz wrote:
It looks like seq for integers bigger than 2^64 sometimes generate wrong
results. There are few examples of wrong output I have found:
$ seq 18446744073709551617 inf | head -3
18446744073709551616
18446744073709551617
18446744073709551618
999731564544
999731564545
999731564546
$ seq -1 0 | head -3
-1
-1
-1
It is similar to bug #75994 which reports the same issue but only for
avidseeker via GNU coreutils Bug Reports writes:
> $ paste -d "␞" file1 file2
>
> results in ␞ (U+241e) character being converted to � (U+FFFD)
>
> paste command doesn't seem to support UTF-8 characters.
Thanks for the report. This is a long standing issue with mor
$ paste -d "␞" file1 file2
results in ␞ (U+241e) character being converted to � (U+FFFD)
paste command doesn't seem to support UTF-8 characters.
Regards,
Avid
> On 8/31/25 18:58, yubiao hu wrote:
>> Yes, this bug was identified via static code analysis. The initial
>> finding that core dump would occur in `cell = xstrdup (mount_point);`
>> when mount_point is NULL.
>
> It appears that the static analysis is reporting a fal
On 8/31/25 18:58, yubiao hu wrote:
Yes, this bug was identified via static code analysis. The initial
finding that core dump would occur in `cell = xstrdup (mount_point);`
when mount_point is NULL.
It appears that the static analysis is reporting a false positive. Which
static analyzer are
> On 29/08/2025 02:45, yubiao hu wrote:
>> * src/df.c (get_dev): Fix potential null pointer dereference
>> - Avoid dereferencing stat_file when both device and
>> mount_point are NULL
>> - Handle allocation failure for cell when mount_point
>> is NULL
>
> These are valid concerns.
> I also see
Why is this patch needed? Can you give an example df invocation in which
> mount_point is null there? As far as I can see, that cannot happen.
>
> Did your bug report come from static analysis? If so, which static
> analyzer did you use and how did you use it? Does the attached patc
strings appropriately.
Instead work out the padding required and use:
printf("%*s%s", padding, "", string) to pad multi-byte appropriately.
* NEWS: Mention the bug fix.
---
NEWS | 4
src/ls.c | 16
2 files changed, 16 insertions(+), 4 deletions(-)
On 30/08/2025 18:52, Pádraig Brady wrote:
On 29/08/2025 02:45, yubiao hu wrote:
* src/df.c (get_dev): Fix potential null pointer dereference
- Avoid dereferencing stat_file when both device and
mount_point are NULL
- Handle allocation failure for cell when mount_point
is NULL
These are v
Paul Eggert writes:
> On 2025-08-28 18:45, yubiao hu wrote:
>> * src/df.c (get_dev): Fix potential null pointer dereference
>> - Avoid dereferencing stat_file when both device and
>> mount_point are NULL
>> - Handle allocation failure for cell when mount_point
>> is NULL
>
> Why is this patch
On 29/08/2025 02:45, yubiao hu wrote:
* src/df.c (get_dev): Fix potential null pointer dereference
- Avoid dereferencing stat_file when both device and
mount_point are NULL
- Handle allocation failure for cell when mount_point
is NULL
These are valid concerns.
I also see potential null dere
Hi,
I'm a GNU/Linux noob so maybe I'm doing something wrong. But see the
attached image for badly formatted output from ls -s1 --block-size=\'k. The
columns are not always aligned. This only happens when you have large files
in the directory. Everything looks fine with --block-size=k.
I'm running
invocation in which
mount_point is null there? As far as I can see, that cannot happen.
Did your bug report come from static analysis? If so, which static
analyzer did you use and how did you use it? Does the attached patch
pacify your static analyzer?
From
On 30/08/2025 04:27, Collin Funk wrote:
Pádraig Brady writes:
Thanks for the suggestion, but that doesn't work. Any issue with
skipping based on $host_os for this test and for fold-spaces.sh?
I was thinking of testing "printf '\u00A0' | ./src/tr -d
'[:blank:]'"
but that won't work since 'tr' o
* src/df.c (get_dev): Fix potential null pointer dereference
- Avoid dereferencing stat_file when both device and
mount_point are NULL
- Handle allocation failure for cell when mount_point
is NULL
---
src/df.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
d
Pádraig Brady writes:
>> Thanks for the suggestion, but that doesn't work. Any issue with
>> skipping based on $host_os for this test and for fold-spaces.sh?
>> I was thinking of testing "printf '\u00A0' | ./src/tr -d
>> '[:blank:]'"
>> but that won't work since 'tr' operates on bytes and U+00A0
On 29/08/2025 05:23, Collin Funk wrote:
Pádraig Brady writes:
Perhaps the techniques from tests/wc/wc-nbsp.sh could be used?
Maybe something like:
check_space() {
char="$1"
# Use -L to determine whether NBSP is printable.
# FreeBSD 11 and OS X treat NBSP as non printable ?
test "$
On Tue, 26 Aug 2025, 07:15 James Feeney, wrote:
> Hey Martin
>
> On Mon, 2025-08-25 at 20:10 +1000, Martin D Kealey wrote:
> > TL;DR locale and timezone are independent; neither implies the other.
>
> Thanks for your note. Short version: your point is taken, and I submit a
> revised argument, an
Pádraig Brady writes:
> Perhaps the techniques from tests/wc/wc-nbsp.sh could be used?
> Maybe something like:
>
> check_space() {
> char="$1"
> # Use -L to determine whether NBSP is printable.
> # FreeBSD 11 and OS X treat NBSP as non printable ?
> test "$(env printf "=$char=" | wc -L)"
Bruno Haible writes:
> Collin Funk wrote:
>> My initial idea was to check if U+2007 FIGURE SPACE and U+00A0 NO-BREAK
>> SPACE are blank using grep. But apparently Solaris grep does not handle
>> multibyte characters. Therefore, FIGURE SPACE cannot be checked. :(
>
> I'm not sure we are talking ab
fix: https://lists.gnu.org/archive/html/bug-coreutils/2025-08/msg00094.html
---
src/expr.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/expr.c b/src/expr.c
index cd87763..534bb44 100644
--- a/src/expr.c
+++ b/src/expr.c
@@ -93,6 +93,7 @@ static VALUE *eval (bool
On 2025-08-28 01:08, Collin Funk wrote:
Most (all?) of the programs in Coreutils will not free memory before
exit, since it just takes extra time for no benefit.
Not only does it take extra time (and sometimes even space!), it makes
the programs slightly less reliable because if there are bugs
Hi,
yubiao hu writes:
> Package: coreutils
> Version: 9.4
> Severity: normal
>
> I was trying to build coreutils with ASan, and found a memory leak in expr.
>
> When running:
> expr length "hello"
>
> Output:
> =
> ==755058==ERROR:
Package: coreutils
Version: 9.4
Severity: normal
I was trying to build coreutils with ASan, and found a memory leak in expr.
When running:
expr length "hello"
Output:
=
==755058==ERROR: LeakSanitizer: detected memory leaks
Direct
On 8/26/25 08:43, James Feeney wrote:
Your definition of "longstanding" seems a bit disingenuous, since this change,
from the default POSIX `date -u` 24 hour format to the 12 hour format, was made in 2020
? No it wasn't. I just now ran 'date -u' from the coreutils 5.93 (2005)
shipped with Sol
On Mon, 2025-08-25 at 15:20 -0700, Paul Eggert wrote:
> >
> > Are you inclined to accept the time format of ISO 8601 for the display of
> > UTC - or no?
>
> We should not change the behavior of plain 'date -u' based on any
> arguments presented so far in this thread. The current behavior is
>
Collin Funk wrote:
> My initial idea was to check if U+2007 FIGURE SPACE and U+00A0 NO-BREAK
> SPACE are blank using grep. But apparently Solaris grep does not handle
> multibyte characters. Therefore, FIGURE SPACE cannot be checked. :(
I'm not sure we are talking about the same thing. I reported
On 26/08/2025 03:24, Collin Funk wrote:
Bruno Haible via GNU coreutils Bug Reports
writes:
Today's CI run reports
FAIL: tests/fold/fold-nbsp
on NetBSD 10 and Solaris 11.4.
The log output in both cases is:
FAIL: tests/fold/fold-nbsp
==
--- exp12025-
Bruno Haible via GNU coreutils Bug Reports
writes:
> Today's CI run reports
> FAIL: tests/fold/fold-nbsp
> on NetBSD 10 and Solaris 11.4.
>
> The log output in both cases is:
>
> FAIL: tests/fold/fold-nbsp
> ==
>
> --- exp1
On 2025-08-25 14:15, James Feeney via GNU coreutils Bug Reports wrote:
For anyone inclined to accept my appeal to ISO 8601, the current display format
returned by `date -u`, especially within the USA, is wrong, and that is a bug
that needs to be fixed.
Are you inclined to accept the time
Hey Martin
On Mon, 2025-08-25 at 20:10 +1000, Martin D Kealey wrote:
> Hi James
>
> On Mon, 25 Aug 2025, 07:33 James Feeney via GNU coreutils Bug Reports,
> wrote:
> > it must also be noted that "UTC" is in *Great Britain*,
>
> To be honest, referring to U
AYS.
>
> Not quite following but I hope the comment is OK now with the first
> patch installed.
>
> > squashfs is giving the wrong info here after all,
> > right?
>
> Yes, that's the actual space-performance bug here. I installed the
> second attached patch to try to work around it.
>
> Jeremy, can you please try these two further patches? Thanks.
On 2025-08-24 14:33, James Feeney via GNU coreutils Bug Reports wrote:
reporting UTC in 12 hour format is just plain wrong.
No it's fine, actually. UTC is a world-wide standard; it's not local to
Greenwich. Many people prefer 12-hour format, and there's nothing wrong
with disp
d *not* "Mountain Daylight Time", in 12 hour format.
We note that `man 1 date` explicitly says that `date -u` will display "UTC"
time:
-u, --utc, --universal
print or set Coordinated Universal Time (UTC)
----
It never occurred to me that UTC could ever b
[CCing bug-gnulib]
Collin Funk wrote:
> On Alpine this is because iswblank in UTF-8 locales is the same as
> isblank in the C locale. This means it only returns 1 for U+0009 TAB and
> U+0020 SPACE.
It is allowed to behave this way.
https://pubs.opengroup.org/onlinepubs/9799919799.20
Bruno Haible via GNU coreutils Bug Reports
writes:
> Today's CI reports a test failure
> FAIL: tests/fold/fold-spaces
> on several systems:
> - Alpine Linux,
> - macOS 13..15,
> - FreeBSD 14.
>
> Here are the relevant parts of the log files.
Thanks.
On Al
Bruno Haible writes:
> Collin Funk wrote:
>> The CentOS 7 one fails because SCHED_DEADLINE is not defined by
>> sched.h. But it is defined in linux/sched.h. The second patch, which is
>> for Gnulib, fixed it in my CentOS 7 container.
>
> This patch would be fine to apply in Gnulib, except that th
Collin Funk wrote:
> The CentOS 7 one fails because SCHED_DEADLINE is not defined by
> sched.h. But it is defined in linux/sched.h. The second patch, which is
> for Gnulib, fixed it in my CentOS 7 container.
This patch would be fine to apply in Gnulib, except that the rationale
(why do we include
On 24/08/2025 10:56, Collin Funk wrote:
Bruno Haible via GNU coreutils Bug Reports
writes:
Today's CI run produces a
FAIL: tests/nproc/nproc-quota
on CentOS 7 and on Alpine Linux.
Here are the two relevant log file portions.
Thanks. The Alpine one fails because sched_getscheduler
Bruno Haible via GNU coreutils Bug Reports
writes:
> Today's CI run produces a
> FAIL: tests/nproc/nproc-quota
> on CentOS 7 and on Alpine Linux.
>
> Here are the two relevant log file portions.
Thanks. The Alpine one fails because sched_getscheduler is a stub that
always
Today's CI reports a test failure
FAIL: tests/fold/fold-spaces
on several systems:
- Alpine Linux,
- macOS 13..15,
- FreeBSD 14.
Here are the relevant parts of the log files.
Alpine Linux:
FAIL: tests/fold/fold-spaces
+ initial_cwd_=/work/coreutils-2025-08-
e the character has been treated like a space.
If you need a correction at the Gnulib level (in the functions iswblank,
iswspace, c32isblank, or c32isspace), please report this to bug-gnulib.
Alternatively, you may declare this a "quality of implementation" issue
and simply disable the test on Net
Today's CI run produces a
FAIL: tests/nproc/nproc-quota
on CentOS 7 and on Alpine Linux.
Here are the two relevant log file portions.
CentOS 7:
FAIL: tests/nproc/nproc-quota
=
++ initial_cwd_=/work/coreutils-2025-08-24/build
+++ testdir_prefix_
+++ printf gt
++ pf
On 2025-08-23 11:46, Phillip Lougher wrote:
As far as Squashfs is concerned SEEK_HOLE/SEEK_DATA is easy to
implement. So I'll think about adding it as a build option.
Thanks, that'll be helpful.
But this isn't going to fix it for any other case.
Right, and bleeding-edge coreutils already h
On 2025-08-23 11:27, Phillip Lougher wrote:
Yeah let's take the attitude everyone writes well written programs, and if they
don't it's their fault when they unexpectedly break in production. In reality
a lot of code in embedded Linux systems is dreadful, written by inexperienced
programmers
On 23/08/2025 17:46, Paul Eggert wrote:
On 2025-08-22 19:11, Phillip Lougher wrote:
any Squashfs SEEK_HOLE/SEEK_DATA implementation will not
behave like other Linux filesystems, because it won't report sparseness
at the 4K granularity that most people or programs will expect it to.
Coreutils
On 23/08/2025 17:46, Paul Eggert wrote:
On 2025-08-22 19:11, Phillip Lougher wrote:
any Squashfs SEEK_HOLE/SEEK_DATA implementation will not
behave like other Linux filesystems, because it won't report sparseness
at the 4K granularity that most people or programs will expect it to.
Coreutils
On 23/08/2025 01:48, Paul Eggert wrote:
On 8/22/25 07:04, Pádraig Brady wrote:
/* Copy this extent, looking for further opportunities to not
bother to write zeros if --sparse=always, since SEEK_HOLE
is conservative and may miss some holes. */
So the comment needs
On 2025-08-22 19:11, Phillip Lougher wrote:
any Squashfs SEEK_HOLE/SEEK_DATA implementation will not
behave like other Linux filesystems, because it won't report sparseness
at the 4K granularity that most people or programs will expect it to.
Coreutils doesn't expect 4 KiB granularity for LSEEK
Jeremy Allison wrote:
> It turns out that: lseek(3, 0, SEEK_HOLE) returns end-of-file for a
> sparse file copied from a Linux squashfs mounted drive. This breaks
> the --sparse=auto heuristic that detects a sparse file.
The reason for this is because Squashfs supports sparse files, but
it has ne
Padraig Brady wrote:
> with --sparse=always. squashfs is giving the wrong info here after
all, right?
No Squashfs is not giving the wrong information here.
Support for SEEK_HOLE/SEEK_DATA is not mandated, and no Linux filesystem
is required to support it.
What you are seeing here is the de
OK now with the first
patch installed.
squashfs is giving the wrong info here after all,
right?
Yes, that's the actual space-performance bug here. I installed the
second attached patch to try to work around it.
Jeremy, can you please try these two further p
A question about this hunk:
@@ -619,9 +615,9 @@ lseek_copy (int src_fd, int dest_fd, char **abuf, size_t
buf_size,
is conservative and may miss some holes. */
off_t n_read;
if ( ! sparse_copy (src_fd, dest_fd, abuf, buf_size,
- true, allow_reflin
Thanks for checking; closing the bug report.
Yes - that seems to fix the problem ! Thanks Paul.
On Thu, Aug 21, 2025 at 4:03 PM Paul Eggert wrote:
>
> Thanks for the bug report. Although this part of the code is messy and
> needs a revamp, in the meantime I installed the attached into the master
> branch on Savannah; please give it a try.
Thanks for the bug report. Although this part of the code is messy and
needs a revamp, in the meantime I installed the attached into the master
branch on Savannah; please give it a try.From b7fc76269bbc830bf96320cd5cca3cfd90d33f68 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Thu, 21 Aug
On Tue, Aug 19, 2025, at 09:13, James Feeney via GNU coreutils Bug Reports
wrote:
>
> Yes, that's it, along with the coincidence that MDT relative to UTC is
> exactly 12 hours.
>
That coincidence is true only in base 4. :)
ttps://askubuntu.com/questions/1238397/ubuntu-server-20-04-time-format-24-hours-on-shell-with-date-command
which comments that:
24-hour clock in en_US locale was a bug in glibc locale definition and has been
corrected in this commit. So, the change was intentional. –
Mateusz
C
It turns out that: lseek(3, 0, SEEK_HOLE) returns end-of-file for a
sparse file copied from a Linux squashfs mounted drive. This breaks
the --sparse=auto heuristic that detects a sparse file.
I have a fix for you to consider.
To reproduce:
First, create a squashfs drive containing a file output_
tag 79261 notabug
close 79261
stop
On 17/08/2025 17:02, James Feeney via GNU coreutils Bug Reports wrote:
Arch Linux
coreutils 9.7-1
$ timedatectl;date;date -u
Local time: Sun 2025-08-17 09:50:24 MDT
Universal time: Sun 2025-08-17 15:50:24 UTC
RTC
On Sun, Aug 17, 2025, at 10:02, James Feeney via GNU coreutils Bug Reports
wrote:
> Arch Linux
> coreutils 9.7-1
>
> $ timedatectl;date;date -u
>Local time: Sun 2025-08-17 09:50:24 MDT
>Universal time: Sun 2025-08-17 15:50:24 UTC
>
Arch Linux
coreutils 9.7-1
$ timedatectl;date;date -u
Local time: Sun 2025-08-17 09:50:24 MDT
Universal time: Sun 2025-08-17 15:50:24 UTC
RTC time: Sun 2025-08-17 15:50:24
Time zone: US/Mountain (MDT, -0600)
System clock synchronized: yes
a file from one file system to another it is impossible to
> have an atomic rename(). In that case mv falls back to effectively cp
> plus rm. That is mentioned in the mv documentation.
If this right here doesn't sound like pseudocode, I don't know what does.
Perfect pseudocode to
Closing this now that the patches are pushed.
Thanks for the help Paul and Pádraig.
Collin
Paul Eggert writes:
> On 2025-08-03 12:47, Collin Funk wrote:
>> How about the wording and formatting of the attatched patch?
>
> Thanks, looks good.
Marking this bug as done since readlink and realpath should now comply
with POSIX 2024. If not, we can treat it as a new bug.
On 8/14/25 21:18, Collin Funk wrote:
Just adding here that POSIX.1-2024 removed the -a and -o operators [1]:
Austin Group Defect 1330 is applied, removing the obsolescent (and
optional) -a and -o binary primaries, and '(' and ')' operators.
So I don't think we should spend much time w
aries, and '(' and ')' operators.
So I don't think we should spend much time worrying about it. That is my
excuse at least.
Will leave this bug report open though.
[1] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/test.html
Paul Eggert writes:
> - parse_gnu_standard_options_only (argc, argv, PROGRAM_NAME, PACKAGE_NAME,
> - Version, true, usage, AUTHORS,
> - (char const *) nullptr);
> + while (true)
The removal of this function call without removi
On 14/08/2025 17:33, Collin Funk wrote:
Paul Eggert writes:
Come to think of it, how about setting MAX_CYCLES to 1? There's no
real use for values greater than 1. This is much simpler (it avoids
the abovementioned problems among other things), and POSIX allows
this. Proposed patch attached.
Pádraig Brady writes:
>> I have attached a proposed patch.
>> I followed the POSIX recommendation of using the exit status 0 - 124
>> for
>> the number of cycles and 125 for program errors (e.g. closing standard
>> output).
>
> -w seems a bit arbitrary to standardize since I only see it in OpenBS
Paul Eggert writes:
> Come to think of it, how about setting MAX_CYCLES to 1? There's no
> real use for values greater than 1. This is much simpler (it avoids
> the abovementioned problems among other things), and POSIX allows
> this. Proposed patch attached.
Haven't tested the patch. But I do n
On 8/13/25 22:01, Collin Funk wrote:
+error (0 <= cycle_count ? MAX_CYCLES + 1 : EXIT_FAILURE, errno, "%s",
This sort of thing is awkward and doesn't suffice anyway since if (say)
xmalloc fails the exit status is wrong. Instead, code should use
initialize_exit_failure to set the desired
On 8/14/25 04:45, Pádraig Brady wrote:
So we could just always exit >= 125 on error, and
it would suffice to mention this in NEWS under "Change in behavior".
But I'm inclined to only do the exit status adjustments if -w was
specified.
and just document the exit status range in the info docs f
On 14/08/2025 06:01, Collin Funk wrote:
Collin Funk writes:
I'll have a look at implementing this behavior. But figured it was worth
sending on bug-coreutils for tracking like the rest of the missing POSIX
2024 features.
I have attached a proposed patch.
I followed the POSIX recommend
Collin Funk writes:
> However, that means that when POSIXLY_CORRECT is not defined the exit
> status is ambiguous as shown in the following example:
>
> # Input with a cycle.
> $ printf 'a b\nb a\n' | ./src/tsort
> tsort: -: input contains a loop:
> tsort: a
> tsort: b
> a
Collin Funk writes:
> I'll have a look at implementing this behavior. But figured it was worth
> sending on bug-coreutils for tracking like the rest of the missing POSIX
> 2024 features.
I have attached a proposed patch.
I followed the POSIX recommendation of using the exit stat
values above that maximum through 125 for other errors, and
leaving values 126 and greater to have the special meanings that the
shell assigns to them.
I'll have a look at implementing this behavior. But figured it was worth
sending on bug-coreutils for tracking like the rest of the mi
Thanks, I installed that.
eger-Import-and-Export .
If yes, then it's a bug in mini-gmp.c around line 4529.
If no, it's a bug in coreutils/src/basenc.c.
If yes, feel free to report that to the GMP people, without CCing me, please.
If no, feel free to apply the attached fix. It passes "make check".
Bruno
On 11/08/2025 11:16, Doctorixx wrote:
Hello coreutils maintainers,
I noticed a potentially dangerous difference in how rm handles the / and /*
patterns.
Currently:
$ sudo rm -rf /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe
This preve
1 - 100 of 17544 matches
Mail list logo
