behave
similarly, neither should loop: they should both output the requested
number of random bytes. Similarly for /dev/zero. I installed the
attached patch to do that.From fb543b6b82c1f3a20ff88f44cc3ed367bfe811b6 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 19 Apr 2024 21:44:32 -0700
umenting this macOS bug in Gnulib by installing the second
attached patch to Gnulib, and am cc'ing this email to bug-gnulib.From 29345117a4cf85aceb88e3901758b19a4867062e Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 19 Apr 2024 00:12:50 -0700
Subject: [PATCH] Fix bug with stat truncating pip
On 4/18/24 14:52, Sergei Trofimovich wrote:
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/fstat.2.html
as
BUGS
Applying fstat to a socket (and thus to a pipe) returns a zero'd buffer,
except for the blocksize field, and a
On 4/17/24 03:19, Pádraig Brady wrote:
Patch looks good, and conforms to POSIX.
Thanks for the review. I installed the patch and am closing this bug report.
.
Rather than document the hybrid mess, let's bite the bullet and fix it.
FreeBSD behavior makes more sense, so let's do that. Proposed patch
attached.From 674a6c262e594102b0485c5ded854c1be5902777 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 16 Apr 2024 15:08:51 -0700
Subject: [PATCH
On 4/16/24 12:44, Pádraig Brady wrote:
A related suggestion was from Marc Chantreux (CC'd)
to support '-' to imply stdin, which would be more portable.
There is some merit to that suggestion too.
I see that merit too, as when 'install' reads from stdin it needn't do
the inode check. However,
On 4/16/24 07:47, Alejandro Colomar wrote:
Since you couldn't reprodude it in a recent Darwin, maybe it's
just a bug in an old Darwin.
It'd have to be pretty old. As near as I can see from
xnu/bsd/kern/sys_pipe.c, the st_ino field was zero (i.e., not random)
even in xnu-792 dated 2005.
I'd
On 2024-04-08 10:59, Ondrej Mejzlik wrote:
The command uname returns "unknown" on Fedora 38,39 and probably 40.
There is a similar very old bug here which has not been fixed
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34905
Indeed there is, and I merged your bug report into that old one.
. My current little task is to get i18n to work better with 'sort'.
Among other things I want Unicode-style full case folding.From 225cb8d7473eadb481a4884e929bf23589d4bd82 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 6 Apr 2024 15:13:23 -0700
Subject: [PATCH 1/4] =?UTF-8?q?cat:=20don=E2=80
On 2024-03-31 12:45, Bruno Haible wrote:
I think you must ask this to yourself:
- What caused you to change the unit tests on 2023-09-04?
- How is the musl version that you used on that date configured?
What I use is Alpine Linux, as I said in versions 3.9, 3.14, 3.19.
- Did you
On 3/31/24 05:22, Pádraig Brady wrote:
On 31/03/2024 10:02, Adept's Lab wrote:
test-canonicalize.c:411: assertion 'strcmp (result1, "//") == 0' failed
^ the only error log message I get. Fail was not presented with previous
stable versions.
This is on musl 1.1.24 as detailed at:
f130f5426ecd4edd5596797e0a5721b927f80126 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 30 Mar 2024 13:28:01 -0600
Subject: [PATCH] time_r-tests: skip French tests if no Europe/Paris
* tests/test-localtime_r.c (main):
* tests/test-localtime_r-mt.c (main):
If TZ='Europe/Paris' does not work, skip these tests
On 3/21/24 14:45, Bernhard Voelker wrote:
On 3/21/24 00:56, Paul Eggert wrote:
On 3/20/24 15:53, Bernhard Voelker wrote:
Yes, that's the expected behavior for this contrived case. Just as one
would get odd behavior if one did the same thing without --exchange.
There's another which
On 3/20/24 15:53, Bernhard Voelker wrote:
$ echo 1 > a
$ mkdir d
$ echo 2 > d/a
$ src/mv -v --exchange a a a d
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
$ cat a
2
$ src/mv -v --exchange a a a d
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
On 3/17/24 04:32, Pádraig Brady wrote:
I think the --no-copy situation is brittle, as scripts not using it now
would be atomic, but then if we ever supported cross fs swaps
it may become non atomic. I'd at least doc with a line in the --exchange
description in usage() to say something like:
On 3/20/24 12:43, Bernhard Voelker wrote:
This stems from the fact that although mv(1) is a userland frontend
for renameat(2), the user interface is different:
while renameat(2) deals exactly with 2 operands, mv(1) has always
been able to work on more arguments.
Yes, that's mv's original sin,
On 3/19/24 08:33, Rafal Maszkowski wrote:
he --debug option advised in
README does not say anything helpful:
(echo a; echo b) | sort --debug -nu
sort: text ordering performed using simple byte comparison
a
^ no match for key
That diagnostic message is helpful. It's telling you that there's no
f8d2c Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 16 Mar 2024 22:50:17 -0700
Subject: [PATCH] mv: new option --exchange
* src/copy.h (struct cp_options): New member 'exchange'.
* src/copy.c (copy_internal): Support the new member.
* src/mv.c (EXCHANGE_OPTION): New constant.
(long_op
On 2024-03-14 06:03, Pádraig Brady wrote:
How about leaving it AC_COMPILE_IFELSE, but ensuring that -O1 or better
is used when the compiler supports -O1? That way we don't have to worry
about running the program, because (with the "volatile") clang will
error out.
Alternatively perhaps
On 2024-03-12 19:24, Grisha Levit wrote:
- AC_COMPILE_IFELSE(
+ AC_RUN_IFELSE(
This sort of change would break cross-compilation, no?
How about leaving it AC_COMPILE_IFELSE, but ensuring that -O1 or better
is used when the compiler supports -O1? That way we don't have to worry
about running
On 2024-03-08 00:49, brian wrote:
Please consider this bug report to be closed. I'm not sure if/how I can
do that via e-mail.
Thanks for following up, and good luck with your hardware or drivers.
Closing the bug report.
On 2024-03-08 05:47, Pádraig Brady wrote:
seq $a | xargs printf -- 'x%.0s'
printf "%${a}s" '' | tr ' ' x
yes x | head -n$a | tr -d '\n'
Oh, I like those! Unfortunately the printf solution silently fails for
me when a=100 due to a bug in Bash. Perhaps I'll get up the
On 3/4/24 12:35, Pádraig Brady wrote:
Another point worth mentioning before changing this,
is that changing would make the --swap operation non symmetric.
I.e. `mv -x a d` would be different to `mv -x d a` where d in a directory.
Yes, of course. It's just like mv without the -x. After you've
On 3/4/24 16:43, Dominique Martinet wrote:
Adding Rob to the loop because this impacts compatibility with
toybox/maybe busybox implementations
Busybox does not use RENAME_EXCHANGE, so this isn't a Busybox issue.
Toybox mv added -x to its development version yesterday:
On 3/4/24 15:37, Petr Malat wrote:
Why do you expect this?
I expect it because mv has always treated destination directories that
way. This has been true since the 1970s. We should not change this basic
mode of operation.
To fix this, 'mv -x' should respect the usual mv behavior with
On 3/4/24 15:16, Petr Malat wrote:
I prefer KISS principle and allowing
swapping just 2 paths.
In that case, the option should be added to the 'rename' command, not to
'mv'.
It is not KISS to add an option to 'mv' that makes it act completely
differently, such that most of mv's other
Try running 'strace -o tr cp data.dat original' and then look at the
file 'tr' (which could be quite large). Look for the syscalls near the
start, and near the end, of the bulk copy.
Quite possibly it's a bug in your Linux drivers or your firmware or
hardware. For example, if you're using
Although I like the idea of exposing file swaps to the user, the first
cut of 'mv -x' has significant problems.
I expect 'mv -x A B' to act like 'mv A B' except the destination must
exist and is renamed back to A. However, this is not true for 'mv -x A
B' when B is a directory; it renames B
On 2024-02-20 12:33, Mathias MICHEL via GNU coreutils Bug Reports wrote:
I don't understand why --hide is depending on whether FILEs were provided
or not to the command. This is the opposite of what Paul stated.
It's not the opposite of what I stated. I said that --hide affects only
files
On 2024-02-18 14:07, Mathias MICHEL via GNU coreutils Bug Reports wrote:
Is it expected that --ignore arg does not apply on globbed FILE ?
Yes. --ignore is about what 'ls' finds in directories, not about
command-line arguments.
My goal is to avoid using grep or complex find args:
>
Thanks. One minor comment about this:
+@item B
+brain 16 bit float
+@item H
+half precision float
It might be helpful explain these two formats, e.g., to cite:
https://en.wikipedia.org/wiki/Bfloat16_floating-point_format
and
On 2/1/24 13:59, Pádraig Brady wrote:
bfloat16 looks like a truncated single precision IEEE,
so we should be able to just pad the extra 16 bits with zeros
when converting to single precision internally for processing.
Sounds good. This would mean od could work even the platform doesn't
Oh, and another thought: suppose someone wants to use od on bfloat16_t
values? They're popular in machine learning applications, and likely
will be more popular than float16_t overall. See:
https://sourceware.org/pipermail/libc-alpha/2024-February/154382.html
Thanks for writing that. One suggestion I'd make is to change this:
#ifndef FLT16_MAX
/* This is just a place-holder to avoid a few '#if' directives.
In this case, the type isn't actually used. */
typedef float _Float16;
#endif
to something like this:
#ifdef FLT16_MAX
typedef
On 1/31/24 06:06, Pádraig Brady wrote:
To my mind the most protective option takes precedence.
That's not how POSIX works with mv -i and mv -f. The last flag wins. I
assume this is so that people can have aliases or shell scripts that
make -i the default, but you can override by specifying
On 2024-01-30 03:18, Pádraig Brady wrote:
So we now have the proposed change as:
- revert -n to old silent success behavior
- document -n as deprecated
- Leave --update=none as is (will be synonymous with -n)
- Provide --update=none-fail to diagnose and exit failure
Thanks, that's
On 1/29/24 08:11, Pádraig Brady wrote:
Right, that's why I'm still leaning towards my proposal in the last mail.
Well, I won't insist on doing nothing; however, the proposal needs
ironing out and now's a good time to do it before installing changes.
- revert to previous exit success
On 2024-01-28 05:22, Pádraig Brady wrote:
At this stage it seems best for us go back to the original Linux
behiavor (use case 3),
and to silently deprecate -n in docs to document the portability issues
with it.
I'm not sure reverting would be best. It would introduce more confusion,
and
On 2024-01-06 07:34, Pádraig Brady wrote:
Though I'm not seeing this suggestion with GCC 13.2.1,
so perhaps GCC 12 can determine the loops are finite?
I'll apply this since GCC 13 is less that a year old,
but in general we try to avoid littering code like this.
I would not apply this, as it's
On 2023-12-16 13:46, Bernhard Voelker wrote:
Whether the implementation is race-prone or not is an internal thing.
I wasn't referring to the internal implementation. I was referring to cp
users. With the newer Coreutils (FreeBSD) behavior, you can reliably
write a script to do something if
On 2023-12-15 10:49, Michael Stone wrote:
There's no compelling reason to force this change
Well, certainly nobody compelled us at gunpoint
Stlll, Pádraig gave a reasonable summary of why the change was made,
despite its incompatibility with previous behavior. (One thing I'd add
is that
On 12/11/23 12:03, Abraham S.A.H. via GNU coreutils Bug Reports wrote:
a sane default behaviour regarding extended attributes in mv and others?
What's wrong with the default behavior in current GNU mv? Please give a
specific example (specify platform, filesystems, mv version, etc.).
That's not a bug, in that 'split' is behaving as documented. The first
input line is one byte shorter than the second one. 'Split' divides the
input into two regions, and because the first region happens to be one
byte longer than the second region both input lines are sent to the
first output
On 11/30/23 12:11, Pádraig Brady wrote:
Though that will generally give 128K, which is good when processing all
of a file,
but perhaps overkill when processing just the last part of a file.
The 128 KiB number was computed as being better for apps like 'sed' that
typically read all or most of
On 2023-11-27 08:24, dann frazier wrote:
+ if (fstat (fd, ) != 0)
+{
+ error (0, errno, _("cannot fstat %s"), quoteaf (pretty_filename));
+ return false;
+}
+
+ bufsize = ST_BLKSIZE (stats);
If fstat fails, that's no reason to exit. Just use bufsize = BUFSIZ and
keep
Thanks. This is a bug in the glibc regular expression matcher. It's part
of a well known series of bugs. See, for example:
https://sourceware.org/bugzilla/show_bug.cgi?id=12896
https://sourceware.org/bugzilla/show_bug.cgi?id=17356
It's not of much practical concern since the attacker should
Thanks for the quick fix for the bug I introduced.
is oddball.From f4a59d453ebfa6dcaf2dd1a89a64c1fa05af7a85 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 25 Oct 2023 08:45:15 -0700
Subject: [PATCH 1/3] build: update gnulib submodule to latest
---
gnulib | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gnulib b/gnulib
On 10/23/23 06:08, Pádraig Brady wrote:
However the default operation should be the
most common requirement (and also the RFC documented operation in this
case).
A similar case I hit very frequently is pasting hex into bc, and it's
very annoying to have to convert to uppercase before doing
On 10/23/23 12:58, petabaud51 wrote:
Could you folks please add it to 'man expr'?
Man pages are supposed to be terse
I looked at the text version of the bug report and don't understand it.
Can you please rephrase the bug report so that you tell us how you
invoked 'paste' (command line arguments and input file contents), what
behavior you expected, and what behavior you observed? Please bear in
mind that your
0
From: JediWisdomKeeper
To: Paul Eggert
Sent with Proton Mail secure email.
--- Original Message ---
On Monday, October 2nd, 2023 at 6:45 AM, Paul Eggert
wrote:
Would you please resend your bug report as plain text? Thanks.Command used: klee --simplify-sym-indices --write-cvcs --wri
Would you please resend your bug report as plain text? Thanks.
/utilities/sort.html#tag_20_119_04From a2434d3e58e8ead6c4c92fd989da32fe648e1545 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Thu, 28 Sep 2023 18:02:25 -0700
Subject: [PATCH] sort: improve --help
Problem reported by Jorge Stolfi (bug#66253).
* src/sort.c (usage): Suggest looking at the man
On my long list of things to do is to have sort -g sort more
deterministically with NaNs. This could be done with the new totalorder
and totalorderl functions in C23 Annex F.10.12.1, if available. The fix
would not be portable (a these functions are newly sort-of-standardized
and are often not
cks setxattr.
However it's bad form. And it means coreutils needs the attached
workaround not just for CIFS, but also for ext4 in some (rare) cases.
I installed the attached workaround on coreutils and am closing the bug
report. Thanks again for mentioning it.From 9cd52bd9993163c2ef8b3d62b757c573fb5320df
On 2023-09-01 19:52, Paul Eggert wrote:
Yes please. If chmod also does not work coreutils might need more
workarounds.
Just to be clear; please try it on a file where chmod should fail
because you don't own the file and you're not root. chmod should fail
with EPERM in this case; it it fails
On 2023-09-01 16:12, Bruno Haible wrote:
Well, you asked me to try it on / but / is an ext4 FS, not a CIFS FS
on my system. Should I try it also on a directory inside the CIFS mount?
Yes please. If chmod also does not work coreutils might need more
workarounds.
Good, thanks for confirming that the chmod family does not have a
similar bug.
I installed the attached workaround into coreutils master on Savannah.
Please give it a try.From 5f971361608749e1245c5eb12096de2acd32bf83 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 1 Sep 2023 15:05:21
On 2023-09-01 08:09, Bruno Haible wrote:
It applies to all 4 variants, as can be seen from applying it to a directory:
$ ./a.out /media/nas/bruno/dir1
lchown: Permission denied
fchownat: Permission denied
chown: Permission denied
fchown: Permission denied
Thanks, for coreutils it'd be helpful
Thanks for the followup. I looked into fixing it in Gnulib and it
appears that this would require an extra syscall (or maybe even two) per
file when copying to a CIFS filesystem, which I'd rather avoid. So I'm
leaning more towards working around the bug in coreutils. Before doing
that, it'd be
On 2023-08-31 08:35, Eric Blake wrote:
Typing-wise, %#s as a synonym for %b is
probably going to be easier (less shell escaping needed). Is there
any interest in a patch to coreutils or bash that would add such a
synonym, to make it easier to leave that functionality in place for
POSIX Issue 9
On 2023-08-29 11:20, Bruno Haible wrote:
People say that "chown only works for root anyway" [1]
I don't think that is the issue here. fchownat is failing with EACCES,
which is supposed to mean that search permission is denied on a
component of the path prefix, but in Android I guess EACCES
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
On 8/22/23 02:58, Osipov, Michael (IN IT IN) wrote:
So no action is required anymore.
Thanks for confirming that. Closing the bug report.
On 8/21/23 05:51, Osipov, Michael (IN IT IN) via GNU coreutils Bug
Reports wrote:
in 9.3 year 2038 support with 64 bit time_t was made required [1], here
on HP-UX this is a bit problematic, but that's not the actual problem.
The diff between 9.2 and 9.3 [2] says how this can be fixed on
On 2023-08-15 14:23, Bruno Haible wrote:
The other patch I mentioned, from
https://lists.gnu.org/archive/html/coreutils/2023-08/msg00028.html ,
is also needed, for the "VM saved/sleep" change on NetBSD, OpenBSD, Minix,
as far as I understand.
Also, a typo in NEWS: s/Minux/Minix/
Thanks, I
On 2023-08-14 00:05, Haoxin Tu wrote:
if the function `fts_read` get a return value of
NULL and the malloc from `fts->fts_cycle.state = malloc (sizeof
*fts->fts_cycle.state)` (Line 62 in fts_cycle.c) is NULL, the pointer
`fts->fts_cycle.state` will still keep 0 before the free operation `free
00:00:00 2001
From: Paul Eggert
Date: Tue, 15 Aug 2023 14:00:54 -0700
Subject: [PATCH 1/2] uptime: be more generous about read_utmp failure
* src/uptime.c (print_uptime): Check for overflow
when computing uptime. Use C99-style decl after statements.
Do not let an idx_t value go negative
On 2023-08-13 02:32, Haoxin Tu wrote:
We have developed a new tool built on top of KLEE (http://klee.github.io/)
to
automatically test GNU Coreutils-9.0 and found there might be a possible
null pointer
dereference
Thanks, but this bug was fixed in coreutils 9.2 (2023-03-20), due to
this
On 2023-08-12 16:00, Bruno Haible wrote:
I see this as a bug. Find attached a fix for this bug. I'll provide a NEWS
entry afterwards, that summarizes the changes in coreutils + gnulib on the
various platforms.
Thanks, this looks good. A NEWS entry would be welcome.
Does this mean Gnulib's
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.
d.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 than where src/filelock.c looks for it.
Ca
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
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
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
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
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&quo
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
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".
. 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
. 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
Date: Thu, 3 A
Thanks for reporting that; I installed the attached.From 93e30466ff6eec8a2cd66374e199017763821478 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 2 Aug 2023 06:47:13 -0700
Subject: [PATCH] pinky: fix "d" typo
Problem reported by Bruno Haible (bug#65003).
* src/pinky.c (idle_st
Thanks, I propagated that into Coreutils and installed the simplified
patch I mentioned yesterday. Closing the coreutils bug report.
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).
On 2023-07-30 11:41, Pádraig Brady wrote:
I'm fine with the change, but we'll also need to adjust
the sc_prohibit_always_true_header_tests syntax check in gnulib
I looked into that but it's such a hassle that I came up with the
attached simpler patch to Coreutils. How about installing it
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
for fixing /'s
Y2038 bugs? (Or is the idea to remove the API before
2038? :-)
See:
https://lwn.net/Articles/925068/
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#utmp_types_and_APIsFrom c408d9a53dbdaf48b555f216e250a2b3b8e48113 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 29 Jul
, and linkat, where the diagnostic could be
improved if it's known to refer to the destination.From 3cb862ce5f10db392cc8e6907dd9d888acfa2a30 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 22 Jul 2023 13:39:17 -0700
Subject: [PATCH] mv: better diagnostic for 'mv dir x' failure
Problem reported by Nir
On 2023-07-22 03:19, Pádraig Brady wrote:
Given the subtleties in this area,
I'd be reluctant to adjust diagnostics here.
I looked into this a bit more. Given "mv dir e" where e/dir is an
existing nonempty directory, 7th Edition Unix fails this way:
mv: e/dir exists
Solaris 10 mv fails
On 2023-07-17 10:12, Pádraig Brady wrote:
Right. In headers though, the traditional "static inline" idiom
Ah, I forgot that it was in system.h. At some point we should have
system.h use _GL_INLINE but that can wait.
On 2023-07-17 03:31, Pádraig Brady wrote:
static inline void
As a general rule, there's no need for 'static inline' in C, as nowadays
compilers figure out inlining just fine for static functions and plain
'static' should be good enough. There are exceptions but 'write_error'
doesn't look
On 2023-07-13 19:38, Budi wrote:
/tmp$ readlink -f ./KERNEL-linux-6.3.9 && echo SUCCEEDS FIND IT
/tmp/KERNEL-linux-6.3.9
SUCCEEDS FIND IT
but correct at deeper depth:
/tmp$ readlink -f ./KERNEL-linux-6.3.9/fs && echo SUCCEEDS FIND IT
look it up, no KERNEL-linux-6.3.9 dir.:
That's not a
On 2023-07-09 07:11, Pádraig Brady wrote:
Note the patch looks wrong as it would close the input always.
We can fix that up easily enough anyway.
If it's easy and doesn't hurt performance in the usual case, that's of
course fine.
For my reference a short list of utils to check (that
On 2023-07-08 15:43, Josef Bacik wrote:
A very weird bug was uncovered when using fstests with github actions.
In fstests we are doing something like this
od /dev/urandom | dd of=somefile bs=1M count=10
The above works fine, except in the case of github actions which runs
this script remotely,
On 2023-06-17 12:53, matoro via GNU coreutils Bug Reports wrote:
Compiling with -D_FILE_OFFSET_BITS=64 fixes the problem.
Thanks for checking. I installed the following fix to coreutils:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=5ac7f2d281ef70500fc70211dc1f146c8666e8c1
This
On 2023-06-17 15:19, Pádraig Brady wrote:
In case it's useful, I noticed this thread from 2014 about ino_t
and consequences of using -D_FILE_OFFSET_BITS=64
https://sourceware.org/pipermail/libc-alpha/2014-March/thread.html#49675
Yes, that was about glibc. For Autoconf and Gnulib it's long been
On 2023-06-17 10:30, Pádraig Brady wrote:
I see that s390 and alpha are the only 64 bit architectures
that have a 32-bit ino_t for example, which may cause issues within glibc?
Weird.
What happens if you compile with -D_FILE_OFFSET_BITS=64? Does this cause
alpha to have a 64-bit ino_t? (How
r attached patches.
I installed these into coreutils on Savannah.From 7814596fa91a07fb2f1d0972f93f26de8a4ad547 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 14 Jun 2023 14:13:35 -0700
Subject: [PATCH 1/3] cksum: fix bug in check for cksum_pclmul
MIME-Version: 1.0
Content-Type: text/plain; cha
91a74d361461494dd546467e83bc36c24185d6e7 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 13 Jun 2023 21:10:24 -0700
Subject: [PATCH] wc: port to kernels that disable XSAVE YMM
Problem reported by Dave Hansen <https://bugs.gnu.org/64058>.
Apply similar change to cksum and pclmul, too.
* NEWS: Mention
1 - 100 of 3246 matches
Mail list logo
