bug#79433: kbd 2.9.0: build error (under fakeroot(1) environment)

On 2025-09-20 13:43, Steffen Nurpmeso wrote: |Anyway, I'm looking into a Gnulib workaround for the fakeroot bug - and |it is a bug, in that fakeroot chown does not conform to POSIX here. That |should fix coreutils as well. It's not a bug in coreutils itself. Thank you! I pus

bug#79446: 9.7: cp(1): Unnecessary writes / incorrect logging messages

ly this behavior is somehow intentional, but I don't see any justification given for this exception to the expected behavior of --update=older or --no-preserve=links. Nor do I. It seems a clear bug, or at least a problem. However, there clearly was intent here: see Pádraig's commit 2aea18

bug#79446: 9.7: cp(1): Unnecessary writes / incorrect logging messages

s somehow intentional, but I don't see any justification given for this exception to the expected behavior of --update=older or --no-preserve=links. Nor do I. It seems a clear bug, or at least a problem. However, there clearly was intent here: see Pádraig's commit 2aea1828a1aab158f68cc

bug#79445: `ln -s` should raise a warning about pwd-relative vs symlink-location-relative targets

PS. This is about more than just learnability for newbies -- this issue tripped me up after 18 years of using Linux as a desktop and/or dev environment, because I ran into the rare case where a program (in this case https://github.com/bbuhrow/yafu/) needed a separate working directory for each inst

bug#79446: 9.7: cp(1): Unnecessary writes / incorrect logging messages

o-preserve=mode to the command, this does prevent the extra call to chmod, but adding --no-preserve=xattr still results in a call to chmod, which seems odd based on your explanation. I've lost context. How do you reproduce the bug? I just now tried "cp -p --no-preserve=mode --no-preserve

bug#79433: kbd 2.9.0: build error (under fakeroot(1) environment)

me to the conclusion that i do not have a problem with Paul Eggert. |Anyway, I'm looking into a Gnulib workaround for the fakeroot bug - and |it is a bug, in that fakeroot chown does not conform to POSIX here. That |should fix coreutils as well. It's not a bug in coreutils itself. Th

bug#79410: Error in expr match handling patterns with null expression subpatterns

thank you for the awesome software you provide to all of us! I found an error in the expr match handling patterns with null expression subpatterns. What I tried to achieve was to append a path string to PATH, but only if it was not already included in PATH; thus I tested with expr match, which w

bug#79433: kbd 2.9.0: build error (under fakeroot(1) environment)

On 2025-09-20 08:57, Steffen Nurpmeso wrote: - Given it seems i have problems with Paul Eggert, for example That wording could be interpreted differently from what you intended. :-) Anyway, I'm looking into a Gnulib workaround for the fakeroot bug - and it is a bug, in that fakeroot

bug#79433: kbd 2.9.0: build error (under fakeroot(1) environment)

normal git view. -dPR is ok! ... |> So anyway the commit message of yours is not right ;) | |Well, the message reflects my understanding of the situation. |Perhaps I am wrong. Sorry to not come back to you after the smoke cleared... |>, and, do you |> know people of coreutils, or

bug#79445: `ln -s` should raise a warning about pwd-relative vs symlink-location-relative targets

Paul Eggert writes: > On 2025-09-13 03:16, Chris wrote: >> It seems to me it should be easy enough to alert users to this gotcha by >> printing a warning to stderr when creating a symlink > > I dunno, that gotcha has been present in Unix and Linux for nearly 50 > years now, and lots of people are

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

Steffen Nurpmeso wrote in <20250918125710.WAELlo5o@steffen%sdaoden.eu>: Sigh. That build system is bogus anyhow, the manual pages are all rebuild when i change a C source file? ... ||>#?0|kent:tmp$ /bin/cp -a xb xc ||>cp: failed to preserve ownership for xc: Operation not supported

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

user, assume no. Why are you running | configure as root, anyway? */ | if (geteuid () == ROOT_UID) return 99; | if (mknod ("conftest.fifo", S_IFIFO | 0600, 0)) return 2; | ; | return 0; | } configure:65601:

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

m not using fakeroot. I don't recommend using fakeroot for 'configure', for all the usual reasons. Fakeroot fails to chown but ignores the error, yet the failed system call avoids getting the filestamp updated. Clearly a bug in fakeroot. POSIX says the file timestamp must be update

bug#79464: stty raw puts terminal in noncanonical mode unconditionally (non-XSI behavior)

^- \ > quit ^- eof ^- eol ^- -post⃰ -inpck > [/XSI] [＊I do believe this is a mistake in the standard: "-post" should read "-opost". I'll file an issue on The Austin Group's bug tracker soon for that.] The GNU version of stty does more; at stty.c:1600 on

bug#79446: 9.7: cp(1): Unnecessary writes / incorrect logging messages

On 2025-09-17 18:19, Paul Eggert wrote: Yes, it's all fairly mysterious. Perhaps someone with more time can look into it. Following up on that a bit. I think part of the problem here is that cp is designed to copy things as efficiently as possible. It's not designed to make minimal changes

bug#79446: 9.7: cp(1): Unnecessary writes / incorrect logging messages

If I add --no-preserve=mode to the command, this does prevent the extra call to chmod, but adding --no-preserve=xattr still results in a call to chmod, which seems odd based on your explanation. I've lost context. How do you reproduce the bug? I just now tried "cp -p --no-preserve=

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

On 2025-09-16 11:51, Steffen Nurpmeso wrote: I attach a tar archives of the two different logfiles, maybe some GNU build system guru can figure out more. The first difference in those logs occurs when 'configure' compiles and run the following program. It should succeed (exit status 0) but in

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

un the following program. It should succeed (exit status 0) but in your Sure. (Just wondering, the final cp(1) should work for all configurable cases if config succeeds; the bug report as such was that "cp -a symlink symlink" causes a "set -e" build script to fail due to the exit

bug#79446: 9.7: cp(1): Unnecessary writes / incorrect logging messages

Hi both, Thanks for the explanations, the trace is making much more sense to me now! > Yes. Unfortunately it's more complicated than the mode, as the > Linux xattr library don't give 'cp' an easy way to  test whether > the extended attributes are identical. We could add this to our > list of thi

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

Steffen Nurpmeso wrote in <20250917164611.JO87MYf4@steffen%sdaoden.eu>: ... |Fakeroot fails to chown but ignores the error, yet the failed |system call avoids getting the filestamp updated. Maybe fakeroot |should "simply" perform the task with the original user and group, |which are availabl

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

fined. However, I'd be surprised if this were the case, as glibc doesn't have that bug as far as I know. lstat64 fstatat64 lchown@plt lchown Thereafter only 10 "??" stepi in between resolved lchow

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

scompilation of gcc 4.2.0? ||| |||I would think not likely, but possible. | ... Do not laugh, but i can actually reproduce building coreutils in my current environment in a way that causes the bug to happen. But i do not know how. But i can give config.log files. I know how now. Just run configu

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

Steffen Nurpmeso wrote in <20250916185103.eUaqIy9H@steffen%sdaoden.eu>: |Steffen Nurpmeso wrote in | <20250916143658.Sac81LV7@steffen%sdaoden.eu>: ||Steffen Nurpmeso wrote in || <20250916122011.vqDfAgh0@steffen%sdaoden.eu>: |||Paul Eggert wrote in ||| : On 2025-09-15 17:40, Steffen Nurp

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

Steffen Nurpmeso wrote in <20250916122011.vqDfAgh0@steffen%sdaoden.eu>: |Paul Eggert wrote in | : ||On 2025-09-15 17:40, Steffen Nurpmeso wrote: ||> How likely is a miscompilation of gcc 4.2.0? || ||I would think not likely, but possible. ... |i'll attach it plzip(1)ped; i now install gdb,

bug#79444: baseenc SIGSEGV on macOS

On 15/09/2025 15:47, Pádraig Brady wrote: On 14/09/2025 15:43, Bruno Haible via GNU coreutils Bug Reports wrote: Pádraig Brady wrote: p.s. an ASAN build would be good for CI The CI already includes an ASAN + UBSAN build: see https://github.com/coreutils/ci-check/blob/master/.github/workflows

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

Paul Eggert wrote in : |On 2025-09-15 17:40, Steffen Nurpmeso wrote: |> How likely is a miscompilation of gcc 4.2.0? | |I would think not likely, but possible. | |If things are working for you know, I wouldn't spend much time worrying |about it. i'll attach it plzip(1)ped; i now install g

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

On 2025-09-15 17:40, Steffen Nurpmeso wrote: How likely is a miscompilation of gcc 4.2.0? I would think not likely, but possible. If things are working for you know, I wouldn't spend much time worrying about it.

bug#79446: 9.7: cp(1): Unnecessary writes / incorrect logging messages

Just to expand a little on Paul's response On Tue, 16 Sept 2025 at 10:14, Paul Eggert wrote: > > 2. The other odd thing in the trace is that there are some kind of odd > > shenanigans going on with the two identical binary files, and a > > third temporary file that cp makes and then remo

bug#79445: `ln -s` should raise a warning about pwd-relative vs symlink-location-relative targets

On Sun, 14 Sept 2025 at 19:15, Chris wrote: > Isn't it better to surprise users who know what they're doing with a > warning, than to surprise users who *don't* know what they're doing with > the lack of one? That's a false dichotomy. In addition to those choices, there's also the option of con

bug#79446: 9.7: cp(1): Unnecessary writes / incorrect logging messages

s 70-80 of the trace, but while I could    accept that they're somehow useful, what definitely seems like a bug    is the message printed (due to being in verbose mode) at line 98 of    the trace. The message makes the claim that a certain file in the    target directory was removed, but

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

ree by worrying about the chown-related syscalls, |>|and that we should instead worry about chmod-related syscalls. |> |> Seems like that. | |On further looking at your trace in |<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79433#23> it seems that I |was mistaken. Even thou

bug#79444: baseenc SIGSEGV on macOS

On 14/09/2025 14:17, Pádraig Brady wrote: There may be more cleanups I might do in this area, but we should commit this fix anyway. While it was fresh in my mind, I refactored the overloaded use of ctx->i as it was confusing to consider all the various uses of it. In the attached there is expl

bug#79444: baseenc SIGSEGV on macOS

On 14/09/2025 15:43, Bruno Haible via GNU coreutils Bug Reports wrote: Pádraig Brady wrote: p.s. an ASAN build would be good for CI The CI already includes an ASAN + UBSAN build: see https://github.com/coreutils/ci-check/blob/master/.github/workflows/many-platforms.yml#L850 named "make

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

. On further looking at your trace in <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79433#23> it seems that I was mistaken. Even though the fchmodat2 syscall fails with ENOSYS, it appears that the glibc fchmodat library function then calls openat with O_NOFOLLOW|O_PATH and then calls f

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

On 2025-09-11 04:49, Steffen Nurpmeso wrote: if (lchownat (dst_dirfd, relname, p->st.st_uid, p->st.st_gid) != 0) ... error (0, errno, _("failed to preserve ownership for %s"), quoteaf (dst_name)); Here there is

bug#79444: baseenc SIGSEGV on macOS

Collin Funk writes: > That is my hypothesis at least, will need to write a patch to test it. Looks like my hypothesis was correct. I ran the CI with the attached patch, and everything passes. I'll hold off pushing until Pádraig checks it. Since he may want to revisit his previous commit and han

bug#79444: baseenc SIGSEGV on macOS

Pádraig Brady writes: > There may be more cleanups I might do in this area, > but we should commit this fix anyway. Done, thanks. Collin

bug#79444: baseenc SIGSEGV on macOS

Pádraig Brady wrote: > p.s. an ASAN build would be good for CI The CI already includes an ASAN + UBSAN build: see https://github.com/coreutils/ci-check/blob/master/.github/workflows/many-platforms.yml#L850 named "make check with sanitizers" in https://github.com/coreutils/ci-check/actions/runs/177

bug#79444: baseenc SIGSEGV on macOS

On 14/09/2025 07:07, Collin Funk wrote: Collin Funk writes: That is my hypothesis at least, will need to write a patch to test it. Looks like my hypothesis was correct. I ran the CI with the attached patch, and everything passes. I'll hold off pushing until Pádraig checks it. Since he may w

bug#79445: `ln -s` should raise a warning about pwd-relative vs symlink-location-relative targets

Isn't it better to surprise users who know what they're doing with a warning, than to surprise users who *don't* know what they're doing with the lack of one? On Sat, Sep 13, 2025 at 11:54 PM Collin Funk wrote: > Paul Eggert writes: > > > On 2025-09-13 03:16, Chris wrote: > >> It seems to me it

bug#79445: `ln -s` should raise a warning about pwd-relative vs symlink-location-relative targets

On 2025-09-13 03:16, Chris wrote: It seems to me it should be easy enough to alert users to this gotcha by printing a warning to stderr when creating a symlink I dunno, that gotcha has been present in Unix and Linux for nearly 50 years now, and lots of people are used to the gotcha would plaus

bug#79446: 9.7: cp(1): Unnecessary writes / incorrect logging messages

Hi all, While trying to use cp for a fairly simple script I'm writing, I noticed two sort of odd things going on. The first might not really be a bug, but I find it rather inconvenient. The second seems to involve a bug, but it doesn't really affect my use-case. The command I c

bug#79444: baseenc SIGSEGV on macOS

Bruno Haible writes: > Here's the relevant output on macOS 13: > > empty1d... > Running command: 'basenc --base64 -d 'empty1d.1' > empty1d.O 2> empty1d.E' > sh: line 1: 79138 Segmentation fault: 11 basenc --base64 -d 'empty1d.1' > > empty1d.O 2> empty1d.E > basenc.pl: test empty1d failed: exit

bug#79445: `ln -s` should raise a warning about pwd-relative vs symlink-location-relative targets

When my current working directory is `/foo` and contains `bar` and I need `/example/bar` to be a symlink to `/foo/bar`, it seems intuitive that `ln -s bar /example/bar` should accomplish that. But it doesn't; instead it makes `/example/bar` a symlink that points to itself, because `ln -s` makes rel

bug#79444: baseenc SIGSEGV on macOS

> > FYI, you probably want to do the following in the CI: > > > >$ export DEBUG=1 > >$ export VERBOSE=1 > > > > This will save the commands being run and their output. And hopefully > > make it easier to debug future issues. Here's the relevant output on macOS 13: empty1d... Running com

bug#79444: baseenc SIGSEGV on macOS

Today's CI (coreutils master, gnulib master) reports a test failure on macOS 13 and macOS 15. On macOS 13: FAIL: tests/basenc/basenc = basenc (GNU coreutils) 2025-09-13 Copyright (C) 2025 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later

bug#79444: baseenc SIGSEGV on macOS

Collin Funk wrote: > FYI, you probably want to do the following in the CI: > >$ export DEBUG=1 >$ export VERBOSE=1 > > This will save the commands being run and their output. And hopefully > make it easier to debug future issues. I'm starting a new CI run [1], with these environment vari

bug#79444: baseenc SIGSEGV on macOS

Bruno Haible via GNU coreutils Bug Reports writes: > Today's CI (coreutils master, gnulib master) reports a test failure on > macOS 13 and macOS 15. > > > On macOS 13: > > FAIL: tests/basenc/basenc > = > [...] > sh: line 1: 70606 Segment

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

NOFOLLOW) = 0 |>lchown("c", 1000, 1000) = 0 |>fchmodat2(AT_FDCWD, "c", 0777, AT_SYMLINK_NOFOLLOW) = -1 ENOSYS \ |>(Function not implemented) |> ^^ | |So far the bug report has been about lchownat. But now you're saying Well i am

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

"c") = 0 newfstatat(AT_FDCWD, "c", {st_mode=S_IFLNK|0777, st_size=1, ...}, AT_SYMLINK_NOFOLLOW) = 0 lchown("c", 1000, 1000) = 0 fchmodat2(AT_FDCWD, "c", 0777, AT_SYMLINK_NOFOLLOW) = -1 ENOSYS (Function not implemented) ^^ So f

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

Paul Eggert wrote in <3fe25ff1-2c46-4d2f-997f-3e9dc9c6c...@cs.ucla.edu>: |On 2025-09-11 04:49, Steffen Nurpmeso wrote: |> if (lchownat (dst_dirfd, relname, p->st.st_uid, p->st.st_gid\ |> ) |> != 0) |>... |> error (0, errno,

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

Hello Martin o/, [i resort a bit] Martin D Kealey wrote in : |On Thu, 11 Sept 2025 at 21:49, Steffen Nurpmeso wrote: ... |> cp: failed to preserve ownership for |> /tmp/.pkgmk/pkg/usr/share/kbd/keymaps/i386/qwertz/sr-latin.map.gz: |> Operation not supported ... |>|>|cp -a is used in th

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

Hi Steffen It's important to note the distinction between ENOSYS “Function not implemented”, which means there's no kernel call available, and ENOTSUP “Operation not supported”, which means the system call exists but the filesystem driver doesn't implement the requested function (either generally

bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?

Hello. During package update of kbd i got a build error cp: failed to preserve ownership for /tmp/.pkgmk/pkg/usr/share/kbd/keymaps/i386/qwertz/sr-latin.map.gz: Operation not supported This ended up as (kbd 2.9.0: build error (under fakeroot(1) environment))[1] which was fixed like [2] (-dPR

bug#79410: Error in expr match handling patterns with null expression subpatterns

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

bug#70411: [bug] install(1) fails to read /dev/stdin on Darwin

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

bug#79301: fold-spaces test failure

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

bug#70411: [bug] install(1) fails to read /dev/stdin on Darwin

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

bug#70411: [bug] install(1) fails to read /dev/stdin on Darwin

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

bug#79300: fold-nbsp test failure

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

bug#79301: fold-spaces test failure

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

bug#79301: fold-spaces test failure

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

bug#79300: fold-nbsp test failure

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: > > $

bug#79301: fold-spaces test failure

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

bug#79301: fold-spaces test failure

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

bug#79300: fold-nbsp test failure

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

bug#79381: patch needed after gnulib changed

Thanks, I installed that and am closing the bug report.

bug#79381: patch needed after gnulib changed

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

bug#79336: [PATCH] df: fix potential null pointer dereference

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

bug#79300: fold-nbsp test failure

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

bug#79369: seq generates wrong sequences for big numbers

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.

bug#79300: fold-nbsp test failure

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

bug#79369: seq generates wrong sequences for big numbers

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

bug#79369: seq generates wrong sequences for big numbers

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

bug#79369: seq generates wrong sequences for big numbers

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

bug#79366: paste -d option not accepting UTF-8

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

bug#79366: paste -d option not accepting UTF-8

$ 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

bug#79336: [PATCH] df: fix potential null pointer dereference

> 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

bug#79336: [PATCH] df: fix potential null pointer dereference

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

bug#79336: [PATCH] df: fix potential null pointer dereference

> 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

bug#79336: [PATCH] df: fix potential null pointer dereference

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

bug#79347: Bad formatting for ls with block-size 'k

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(-)

bug#79336: [PATCH] df: fix potential null pointer dereference

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

bug#79336: [PATCH] df: fix potential null pointer dereference

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

bug#79336: [PATCH] df: fix potential null pointer dereference

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

bug#79347: Bad formatting for ls with block-size 'k

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

bug#79336: [PATCH] df: fix potential null pointer dereference

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

bug#79300: fold-nbsp test failure

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

bug#79336: [PATCH] df: fix potential null pointer dereference

* 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

bug#79300: fold-nbsp test failure

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

bug#79300: fold-nbsp test failure

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 "$

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

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

bug#79300: fold-nbsp test failure

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)"

bug#79300: fold-nbsp test failure

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

bug#79331: [PATCH] expr: fix memory leaks

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

bug#79328: expr: memory not freed before program exit(memory leak)

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

bug#79328: expr: memory not freed before program exit(memory leak)

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:

bug#79328: expr: memory not freed before program exit(memory leak)

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

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

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

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

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 >

  1   2   3   4   5   6   7   8   9   10   >