ler in
<https://lists.gnu.org/archive/html/bug-gnulib/2021-08/msg00153.html>.
* lib/sigsegv.c (SIGSEGV_FAULT_STACKPOINTER) [macOS/powerpc: On Mac OS X
<= 10.4, assume struct field names without underscores.
diff --git a/lib/sigsegv.c b/lib/sigsegv.c
index d0519814eb..6d0899
> > Here's a better patch: (technically, we could factor it somewhat, but
> > > readability would suffer disproportionately)
> >
> > I didn't take the time to find a precise commit, but this bug predates
> > the move from closeout.c to gnulib's close-s
Pádraig Brady wrote:
> bs=0
> ws=4095: printf: write error
> ws=4096: printf: write error
> ws=4097: printf: write error
> bs=4096
> ws=4095: printf: write error: No space left on device
> ws=4096: printf: write error
> ws=4097: printf: write error
> bs=8192
> ws=4095: printf: w
on rawhide (because with 4k BUFSIZ, the fclose wrote nothing -- the
preceding 4096-byte write is what failed).
Here's a better patch: (technically, we could factor it somewhat, but
readability would suffer disproportionately)
I didn't take the time to find a precise commit, but this bug pr
suffer disproportionately)
>
> I didn't take the time to find a precise commit, but this bug predates
> the move from closeout.c to gnulib's close-stdout.c in 2006. As I
> write this, I'm installing Fedora 42.
> I'll probably push the attached to gnulib tomorro
On Fri, Apr 18, 2025 at 1:51 AM Jim Meyering wrote:
>
> Surprised to find that coreutils-9.5 (fedora 41 stock) works fine:
>
> $ { /bin/printf %4095s; /bin/printf %4096s; } > /dev/full
> /bin/printf: write error: No space left on device
> /bin/printf: write error: No space left on device
Th
grep --help > /dev/full
>
> :
> src/grep: write error: No space left on device
To reproduce the test failure originally reported, apply the patch I
mentioned in https://lists.gnu.org/r/bug-grep/2025-04/msg00015.html,
i.e.:
https://src.fedoraproject.or
On Thu, Apr 17, 2025 at 11:15 PM Grisha Levit wrote:
>
> On Fri, Apr 18, 2025 at 1:51 AM Jim Meyering wrote:
> >
> > Surprised to find that coreutils-9.5 (fedora 41 stock) works fine:
> >
> > $ { /bin/printf %4095s; /bin/printf %4096s; } > /dev/full
> > /bin/printf: write error: No space left
FSIZ, the fclose wrote nothing -- the
> preceding 4096-byte write is what failed).
>
> Here's a better patch: (technically, we could factor it somewhat, but
> readability would suffer disproportionately)
I didn't take the time to find a precise commit, but this bug predate
; > Here's a better patch: (technically, we could factor it somewhat, but
> > > readability would suffer disproportionately)
> >
> > I didn't take the time to find a precise commit, but this bug predates
> > the move from closeout.c to gnulib's close-st
The Cygwin people don't stop adding regressions in the newest Cygwin
versions. Now it's reading from /dev/null that is broken. It makes
all mingw and MSVC builds fail.
This patch adds a workaround.
2025-04-14 Bruno Haible
select tests: Work around a Cygwin bug.
*
> vasnprintf tests: Add a test case that showcases a Solaris bug.
> * tests/test-vasnprintf-posix2.c (main): Add one more %'g test.
Oops, MSVC gives a compilation error "error C2177: constant too big".
This patch fixes it.
2025-04-13 Bruno Haible
Haiku supports the ' flag in sprintf but not in swprintf. Document this:
2025-04-13 Bruno Haible
*printf: Document a Haiku bug.
* doc/posix-functions/fwprintf.texi: Mention the missing ' flag support.
* doc/posix-functions/vfwprintf.texi: Likewise.
*
Bruno Haible via Gnulib discussion list writes:
> In printf implementations, it is easy to miss the fact that for %.50g
> the implementation needs to allocate room for the thousands-separators.
> I checked various systems, and Solaris printf() was found to crash in
> such circumstances.
Good cat
create a CVE,
based on <https://www.illumos.org/issues/17383>.
2025-04-12 Bruno Haible
vasnprintf tests: Add a test case that showcases a Solaris bug.
* tests/test-vasnprintf-posix2.c (main): Add one more %'g test.
* tests/test-vasnwprintf-posix2.c (main): Like
On Cygwin 3.6.0, I see the test-getlocalename_l test fail: it crashes.
Reported at <https://cygwin.com/pipermail/cygwin/2025-March/257715.html>.
This patch provides a workaround:
2025-03-24 Bruno Haible
getlocalename_l-unsafe: Work around Cygwin 3.6.0 bug.
* m4/local
On Mon, Mar 10, 2025 at 06:24:45AM +0100, Bruno Haible via GNU coreutils Bug
Reports wrote:
> I wrote:
> > Thus, on Linux systems, a correct implementation of getlogin() can not
> > distinguish different users with the same uid (with reasonable effort).
> > This applies to b
keable:
>
> s/this/thus/ ?
Oops, thanks for reporting this. Fixed:
2025-03-19 Bruno Haible
getlogin, getlogin_r: Fix typo in documentation.
Reported by Eric Blake in
<https://lists.gnu.org/archive/html/bug-gnulib/2025-03/msg00071.html>.
* doc/posix-fun
Collin Funk wrote:
> Also reported the bug and mentioned it in the docs [2].
Thanks!
> Looking at the
> code, NetBSD has a similar situation so I documented that too [3].
Indeed, I had apparently forgotten to document this one. Thanks.
Bruno
a bit mask instead
of exiting early.
Also reported the bug and mentioned it in the docs [2]. Looking at the
code, NetBSD has a similar situation so I documented that too [3].
Collin
[1] https://lists.gnu.org/archive/html/bug-gnulib/2025-03/msg00058.html
[2] https://sourceware.org/bugzilla/s
Hi Collin,
> The following test fails on GNU/Hurd:
>
> test-utimens.h:80: assertion 'func (BASE "file", ts) == -1' failed
> FAIL test-utimensat (exit status: 134)
>
> This is because utimensat does not validate the tv_nsec fields of it's
> a
unk
+ utimensat: Increment serial number for previous commit.
+ * m4/utimensat.m4: Increment serial number.
+
utimensat: Work around a GNU/Hurd bug.
* lib/utimensat.c (rpl_utimensat) [__gnu_hurd__]: Check for out of range
tv_nsec values.
diff --git a/m4/utimensat.m4 b/m4/utimensat.m4
index 1a3802a
The following test fails on GNU/Hurd:
test-utimens.h:80: assertion 'func (BASE "file", ts) == -1' failed
FAIL test-utimensat (exit status: 134)
This is because utimensat does not validate the tv_nsec fields of it's
arguments.
I have reported this bug to the h
getlogin, getlogin_r: Document limitation.
Reported by Nicolas Boos in
<https://lists.gnu.org/archive/html/bug-gnulib/2025-03/msg00033.html>.
* doc/posix-functions/getlogin.texi: Mention the "different user names
with same uid" limitation.
On 2025-03-09 11:49, Bruno Haible wrote:
Nicolas Boos wrote:
This page says that the result of the logname command and the LOGNAME
variable must be the same:
https://www.ibm.com/docs/en/aix/7.3?topic=l-logname-command
An AIX man page is not a specification for what we run on GNU systems.
Plus
Nicolas Boos wrote:
> This page says that the result of the logname command and the LOGNAME
> variable must be the same:
> https://www.ibm.com/docs/en/aix/7.3?topic=l-logname-command
An AIX man page is not a specification for what we run on GNU systems.
> Thus, getlogin() implementations that use
> Password:
> # logname
> bruno
>
> Paul, Pádraig: How about adding a coreutils/NEWS entry for this bug fix?
>
> Bruno
>
>
>
>
>
>
$ su -
Password:
# logname
bruno
Paul, Pádraig: How about adding a coreutils/NEWS entry for this bug fix?
Bruno
name
bruno
$ su -
Password:
# logname
root
Now:
$ logname
bruno
$ su -
Password:
# logname
bruno
Paul, Pádraig: How about adding a coreutils/NEWS entry for this bug fix?
I pushed an update to coreutils NEWS mentioning the fix.
Marking this as done.
thanks!
Pádraig.
m gnulib.
2025-03-09 Bruno Haible
getlogin_r: Work around musl bug.
* lib/getlogin_r.c (getlogin_r): Add implementation for Linux.
* m4/getlogin_r.m4 (gl_FUNC_GETLOGIN_R): Test whether getlogin_r has the
musl bug.
* tests/test-getlogin_r.c (main):
On 2025-03-08 08:46, Nicolas Boos via GNU coreutils Bug Reports wrote:
It seems getlogin() is malfunctioning only with glibc.
It's the other way round: glibc is right (in the sense that it conforms
to POSIX) and the other two are wrong.
Adding a permanent fix to gnulib/getlogin.c
Thank you for quick fix Bruno! I'll use host-cpu-c-abi.m4 serial 19 and
somehow make the Debian packaging of guile-fibers 1.3.1 use it. I think
host-cpu-c-abi.m4 should be added to upstream guile-fibers m4/ too, and
will try to work on that (they could use gnulib-tool and/or bootstrap
but I'll pr
gt; gl_cv_host_cpu_c_abi_32bit=unknown ;;
This change is correct, but is missing a corresponding change for loongarch32.
I'm applying the patch below instead.
[1] LoongArch toolchain conventions,
https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-
Thank you!
I think the patch below belongs better to gnulib's m4/host-cpu-c-abi.m4,
could you propose a patch for it instead? Or if someone on the gnulib
list (cc'ed) has ideas how to adapt the patch below into gnulib.
https://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/host-cpu-c-abi.m4
I thi
his commit to gnulib. Paul, does it
work for you (after installing package 'systemd-devel' and rebuilding
coreutils with --enable-systemd)?
2025-02-19 Bruno Haible
readutmp: Let callers distinguish LOGINs from USERs.
Reported by Paul Eggert in
<https://list
* Paul Eggert [250219 21:47]:
> On 2/19/25 09:41, Arsen Arsenović wrote:
> > they (gdm) are a user and they have a session.
> > Adding additional filtration can only confuse admins who compare 'who'
> > and other tools.
>
> It is exactly that confusion that I'm trying to prevent.
>
> The man pag
* Chris Hofstaedtler [250219 22:41]:
> > The man page for "who" says "who - show who is logged on", but gdm is not
> > logged on.
[..]
> I don't really know my way around the sd-logind API, but it looks
> like filtering on the session class (returned by sd_session_get_class)
> might be fruitful.
On 2/19/25 09:41, Arsen Arsenović wrote:
they (gdm) are a user and they have a session.
Adding additional filtration can only confuse admins who compare 'who'
and other tools.
It is exactly that confusion that I'm trying to prevent.
The man page for "who" says "who - show who is logged on", bu
Paul Eggert writes:
> On 2025-02-19 03:26, Arsen Arsenović wrote:
>> The case for or against there being a user called 'gdm' when one
>> installs a Fedora system is one best presented to the Fedora hackers
>
> It's not just Fedora, it's also Ubuntu. Both systems have pseudousers named
> "gdm" tha
On 2025-02-19 03:26, Arsen Arsenović wrote:
The case for or against there being a user called 'gdm' when one
installs a Fedora system is one best presented to the Fedora hackers
It's not just Fedora, it's also Ubuntu. Both systems have pseudousers
named "gdm" that cannot log in (their login sh
Arsen Arsenović wrote:
> Sure, but one cannot name two users on a Unix system 'gdm', and there is
> a passwd entry for 'gdm', so that scenario is impossible (save for
> administrative errors):
>
> arsen@fedora:~$ grep gdm /etc/passwd
> gdm:x:42:42:GNOME Display Manager:/var/lib/gdm:/usr/sbin/n
Bruno Haible writes:
> Arsen Arsenović wrote:
>> This is correct, though, there is a session for the user 'gdm', and
>> they're taking up tty1. If you walk up to that computer (you said you
>> were using SSH, so I assume you're remote), you'll see GDM running on
>> the screen (on one of the virt
Paul Eggert writes:
>> 'who' merely reports the info it got from systemd-logind, and systemd-logind
>> most probably got a notification from gdm.
>> I agree with you that this _looks_like_ as if a user named 'gdm' was logged
>> in, and thus is misleading. But I don't think this should be fixed in
Arsen Arsenović wrote:
> >> I agree with you that this _looks_like_ as if a user named 'gdm' was logged
> >> in, and thus is misleading. But I don't think this should be fixed in
> >> coreutils. Rather, this is something to work out between systemd-logind
> >> and gdm.
> >
> > OK, but until that's
On 2025-02-17 00:22, Thorsten Kukuk wrote:
Maybe that systemd version is too old on that systems?
The systemd versions are reasonably recent. Fedora 41 has systemd 256.11
(2025-01-08) and Ubuntu 24.10 has systemd 256.5 (2024-08-31). Here are
the details:
On Fedora 41, "systemctl --version"
On Mon, Feb 17, 2025 at 10:08 AM Paul Eggert wrote:
> Even if it's that simple, something is updating the traditional
> /var/run/utmp and /var/log/wtmp files on Fedora and Ubuntu and at least
> in some cases they work better than systemd does and this should be
> fixed somehow.
Applications are
On 2025-02-17 00:12, Bruno Haible wrote:
Paul Eggert wrote:
$ ./who-no-systemd # Configured normally.
eggert seat02025-02-15 10:11 (login screen)
eggert tty2 2025-02-15 10:11 (tty2)
$ ./who-with-systemd # Configured with --enable-systemd.
eggert seat0
On Mon, Feb 17, 2025 at 8:40 AM Paul Eggert wrote:
>
> On 2025-02-16 23:03, Thorsten Kukuk wrote:
> > The problems were already all solved with the first coreutils versions
> > having systemd-logind support. Even with all the bug reports I don't
> > see a need for
Paul Eggert wrote:
> If I configure current (f2e323430193956709aacca33f6b4fcab4fb9d8b)
> Coreutils with --enable-systemd on my Ubuntu 24.10 desktop, the output
> gets worse:
>
>$ ./who-no-systemd # Configured normally.
>eggert seat02025-02-15 10:11 (login screen)
>eggert
On 2025-02-16 23:03, Thorsten Kukuk wrote:
The problems were already all solved with the first coreutils versions
having systemd-logind support. Even with all the bug reports I don't
see a need for changes in Coreutils, only in distributions not
enabling systemd-logind support in all pac
Kirill Makurin wrote:
> The installer from https://osdn.net/projects/mingw/ is the same as
> found in https://sourceforge.net/projects/mingw/ (except for possible
> difference in versions) and the Wikipedia article points to the former
> website (mingw.org website is no longer alive). This installe
I tested updated patches and they work for both Msys2 and *MinGW*. For
completeness, I also tried using it from Cygwin and it works as expected.
From: bug-automake-bounces+maiddaisuki=outlook@gnu.org
on behalf of Bruno
Haible via Bug reports for Automake
-*` (gcc,
binutils) and `msys-*` (bash, autotools, etc.) packages. I am using its
`msys.bat` to start the shell.
I also would like to notice that mingw32 (MinGW) has not been updated for a few
years as of now.
From: bug-automake-bounces+maiddaisuki=outlook
Collin Funk wrote:
> As promised, I have pushed the attached patch that fixes the test.
>
> The issue is pretty simple. The strerrorname_np function on this OmniOS
> version returns NULL when given ERESTART or ESTRPIPE. I created a bug
> report for Illumos so hopefully it will ge
ched patch that fixes the test.
The issue is pretty simple. The strerrorname_np function on this OmniOS
version returns NULL when given ERESTART or ESTRPIPE. I created a bug
report for Illumos so hopefully it will get fixed at some point [1].
Collin
[1] https://www.i
ases. Namely, if the test fails on some new platform,
> we would like to document the bug on that platform. If each possible
> bug corresponds to a distinct exit code, we can determine the bug
> by looking into config.log — no need to run a modified test program
> manually.
Collin Funk wrote:
> The renameatu and rename tests fail on GNU/Hurd since renameat2 on that
> platform does not properly handle trailing slashes. I've reported that
> bug with a test case [1].
>
> Applied the attached patch which adds a configure check and documents
> t
The renameatu and rename tests fail on GNU/Hurd since renameat2 on that
platform does not properly handle trailing slashes. I've reported that
bug with a test case [1].
Applied the attached patch which adds a configure check and documents
the bug.
[1] https://sourceware.org/bugzilla/show_bu
Hi Pádraig,
> A small issue with the readutmp test is it fails on systems with an uptime >=
> 5 years.
> cfarm135 is such a system currently, and the test fails like:
>
> FAIL: test-readutmp
> ===
> Here are the read_utmp results.
> Flags: B = Boot, U = User Process
> Time (
On 30/07/2023 14:21, Bruno Haible wrote:
Paul Eggert wrote:
+static void
+copy_utmp_entry (STRUCT_UTMP *dst, STRUCT_UTMP *src)
+{
+#if __GLIBC__ && _TIME_BITS == 64
+ /* Convert from external form in SRC to internal form in DST.
+ It is OK to convert now, rather than earlier, before
+ d
This is mostly to document the bug.
If these old platforms were still common I suppose we should
change the readdir module to work around it. However, I’m not
sure it’s worth the hassle at this point.
* doc/posix-functions/readdir.texi, doc/posix-functions/readdir_r.texi:
Document the bug.
* lib
But it is obviously related to the glibc bug
https://sourceware.org/bugzilla/show_bug.cgi?id=32024
and gnulib has a workaround, in module 'sys_un-h'.
Thanks for letting me know! 'sys_un-h' worked for me.
Miro Palmu**
On 2025-01-11 08:48, Pádraig Brady wrote:
The attached gnulib patch does that.
Thanks for fixing that.
---. 1 padraig padraig 0 Jan 8 20:42 file
I'll push that ls patch now.
Thanks, but I'm not sure that resolves all the issues that can occur
when [l]listxattr returns -1 with errno==EACCES or errno==E2BIG. In this
case we've fixed the bug where the file has a security context but no
void *memchr (void *__s, int __c, size_t __n)
>| ^~
I don't reproduce this error, with your sample.
But it is obviously related to the glibc bug
https://sourceware.org/bugzilla/show_bug.cgi?id=32024
and gnulib has a workaround, in module 'sys_un-h'.
202
m4 - module canonicalize
- m4/malloc.m4 - modules eealloc, malloca
Fixed through the two patches below.
2025-01-11 Bruno Haible
eealloc, malloca: Fix module dependencies.
Reported by Miro Palmu in
<https://lists.gnu.org/archive/html/bug-gnulib/2025-01/msg00077.html>
27;ll push that ls patch now.
Thanks, but I'm not sure that resolves all the issues that can occur
when [l]listxattr returns -1 with errno==EACCES or errno==E2BIG. In this
case we've fixed the bug where the file has a security context but no
NFSv4 or POSIX ACLs. But what if the file
Hi
This email is to report somewhat convoluted bug,
as it is related to the libc function replacements
and how they breaks under specific circumstances
(C++, GNULIB_NAMESPACE, without optimization, including sys/un.h).
By breaking I mean it will not compile due to declarations
with conflicting
, but I'm not sure that resolves all the issues that can occur
when [l]listxattr returns -1 with errno==EACCES or errno==E2BIG. In this
case we've fixed the bug where the file has a security context but no
NFSv4 or POSIX ACLs. But what if the file has those ACLs?
On 10/01/2025 04:46, Paul Eggert wrote:
On 2025-01-09 05:29, Pádraig Brady wrote:
over NFS with unreadable files
you can GET the security.selinux xattr, but you can't LIST any xattrs:
Ouch again
Also there was a change since coreutils v9.5 where we don't call the GET,
Yes, that is fo
On 2025-01-09 05:29, Pádraig Brady wrote:
over NFS with unreadable files
you can GET the security.selinux xattr, but you can't LIST any xattrs:
Ouch again
Also there was a change since coreutils v9.5 where we don't call the GET,
Yes, that is for efficiency in the common case where the
* doc/posix-functions/utimensat.texi (utimensat):
Mention Linux kernel bug reported by Bruno Haible in:
https://lists.gnu.org/r/bug-tar/2024-12/msg4.html
---
ChangeLog | 7 +++
doc/posix-functions/utimensat.texi | 3 +++
2 files changed, 10 insertions(+)
diff
-stackoverflow2
===
*** longjmp causes uninitialized stack frame ***: terminated
FAIL test-sigsegv-catch-stackoverflow2 (exit status: 134)
This is triggered by the _FORTIFY_SOURCE=2 setting in diffutils/configure.ac.
This patch documents the bug and adds a
812ea2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2024-12-12 Paul Eggert
+
+ atexit: document z/OS bug
+ * doc/posix-functions/atexit.texi: Mention z/OS issue
+ raised by Sachin <https://bugs.gnu.org/74788>.
+
2024-12-12 Bruno Haible
bcp47: Sile
-0.23.tar.lz (8.7MB)
https://ftp.gnu.org/gnu/gettext/gettext-0.23.tar.xz (11MB)
2024-12-01 Bruno Haible
announce-gen: Fix bug when accessing symlinks.
* build-aux/announce-gen (sizes): Pass the option -L to 'du'.
diff --git a/build-aux/announce-gen b/build-aux/an
&& CODE < 128 ?
unicode_to_mb was designed for specific characters like the Copyright sign
or the quotation marks. For plain ASCII characters you can bypass it.
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-02/msg00123.html
[2] https://lists.gnu.org/archive/html/bug-gnulib/20
cannot reliably distinguish the type of @code{nullptr}
from integer or @code{void *} types. C++ overloading has similar
limitations.
+
+@item
+GCC 14 defines @code{nullptr_t} even when @code{} is not
+included. This bug should be fixed in GCC 15.
@end itemize
@node static_assert
--
2.43.0
Pádraig Brady wrote:
> and tested the attached code, which I'll push later.
Looks good, except for a typo in comment: Simplifiy → Simplify
Thanks.
Bruno
On 19/11/2024 17:34, Bruno Haible wrote:
Pádraig Brady wrote:
I would prefer to bypass the ASCII case if CODE >= 0 && CODE < 128.
However is that generally correct?
Yes, at least for CODE >= 32 && CODE < 128 it is correct.
This can be seen from the list of supported locale encodings in
gnulib/
On 19/11/2024 04:41, Grisha Levit wrote:
The u4 and U8 tests in tests/printf/printf-cov.pl fail on macOS 15:
u4...
printf: test u4: stdout mismatch, comparing u4.1 (expected) and u4.O (actual)
*** u4.1Mon Nov 18 23:30:03 2024
--- u4.OMon Nov 18 23:30:03 2024
***
*** 1
e ever reported a problem with gperf-
generated C code, that assumes an ASCII-compatible encoding.
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnu-libiconv/2023-04/msg00019.html
[2] https://lists.gnu.org/archive/html/bug-gnu-libiconv/2023-05/msg2.html
icode_to_mb was designed for specific characters like the Copyright sign
or the quotation marks. For plain ASCII characters you can bypass it.
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-02/msg00123.html
[2] https://lists.gnu.org/archive/html/bug-gnulib/2024-02/msg00217.html
On 11/11/2024 16:47, Paul Eggert wrote:
On 2024-11-10 05:48, Pádraig Brady wrote:
BTW I've pushed a tweak to gnulib to avoid a -Werror=unused-variable
issue with --disable-acl
Thanks, I installed the attached further patch, since the res5t of the
file uses MAYBE_UNUSED.
Thanks for all the fi
On 2024-11-10 05:48, Pádraig Brady wrote:
BTW I've pushed a tweak to gnulib to avoid a -Werror=unused-variable
issue with --disable-acl
Thanks, I installed the attached further patch, since the res5t of the
file uses MAYBE_UNUSED.From 6a018d0492239d01c2cc8fd56a1acec4d6fcd44d Mon Sep 17 00:00:0
Another Haiku bug, found while porting GNU clisp:
2024-11-01 Bruno Haible
select: Document a Haiku bug.
* doc/posix-functions/select.texi: Mention a Haiku bug.
diff --git a/doc/posix-functions/select.texi b/doc/posix-functions/select.texi
index 148c4af3ce..6827a3acc7 100644
(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index eb0e39c9fd..4e9bcd72d6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
2024-10-29 Paul Eggert
+ malloc: fix recent doc bug for AIX 7.3
+ * doc/posix-functions/malloc.texi: Undo previous change,
+ as
* doc/posix-functions/aligned_alloc.texi:
* doc/posix-functions/posix_memalign.texi: Mention glibc bug
32301, which it is not worth our time to work around.
---
ChangeLog | 5 +
doc/posix-functions/aligned_alloc.texi | 5 +
doc/posix-functions
/ChangeLog
index 6d8a1a52b3..cea31f84e6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
2024-10-04 Paul Eggert
+ mktime: fix timegm bug that set tmp->tm_isdst
+ * lib/timegm.c (__timegm64): Omit now-unnecessary initialization
+ of tm_isdst. Anyway, the initializat
This patch fixes a bug dating back to 2021-12-28.
2024-09-14 Bruno Haible
unilbrk: Fix bug in implementation of Unicode rule (LB16).
* lib/gen-uni-tables.c (output_lbrk_rules_as_tables): Fix typo.
* lib/unilbrk/lbrktables.c: Regenerated.
diff --git a/lib/gen-uni
strtold: Work around a Haiku bug.
* lib/strtod.c (HAVE_UNDERLYING_STRTOD): Set to 0 for 'long double'
parsing on Haiku.
* doc/posix-functions/strtold.texi: Mention the bug.
diff --git a/doc/posix-functions/strtold.texi b/doc/posix-functions/strtold.texi
index 3
#x27;ILOGB (NAN) == FP_ILOGBNAN' failed
Abort
FAIL test-ilogbl (exit status: 149)
are caused by a workaround that I added, for a bug that is now fixed for
more than a year. Time to revert this workaround.
2024-09-01 Bruno Haible
math: Remove workaround for an older Haiku bug.
* lib/
t way.
If more platforms are affected, we should consider to adapt the autoconf
test from m4/mknod.m4 to m4/mkfifoat.m4. I haven't done this yet.
2024-08-30 Bruno Haible
mkfifoat: Work around a Haiku bug.
* lib/mknodat.c (rpl_mknodat): On Haiku, handle S_IFIFO explicitly.
In m4/mknod.m4 there is a workaround against a bug found on macOS and
DragonFly. Let me document it.
2024-08-30 Bruno Haible
doc: Mention an mknod bug.
* doc/posix-functions/mknod.texi: Mention the S_IFIFO flag bug.
diff --git a/doc/posix-functions/mknod.texi b/doc/posix
On 27/08/2024 22:34, Paul Eggert wrote:
I'm not seeing that false alarm when building coreutils v9.5 on Ubuntu
24.04 LTS with "./configure --enable-gcc-warnings CC=gcc-14".
What GCC version are you using? If it's not GCC 14, try upgrading. I'm
using gcc-14 (Ubuntu 14-20240412-0ubuntu1) 14.0.1 20
On 2024-08-27 04:15, Marc Nieper-Wißkirchen wrote:
However, see the second code block in Example 4 of section 6.7.3.1 (in the
latest draft of C23). This may, of course, be itself an error as the
example is about restrict and not about uninitialized structs.
Yes, that example sheds no light on
Am Do., 22. Aug. 2024 um 07:27 Uhr schrieb Paul Eggert :
> On 2024-08-21 06:36, Bruno Haible wrote:
> > In summary, this paragraph makes no sense for structs.
>
> Hmm, well, the paragraph makes sense to me. I suppose somebody could
> fire off a question to the C committee about the intent of the p
ings or some
other option that defines it.
Collin
[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00122.html
On 2024-08-21 06:36, Bruno Haible wrote:
In summary, this paragraph makes no sense for structs.
Hmm, well, the paragraph makes sense to me. I suppose somebody could
fire off a question to the C committee about the intent of the paragraph.
In the meantime it's an engineering decision - should
Paul Eggert wrote:
> > Copying and then discarding an uninitialized value of integer
> > or pointer type (i.e. not a signalling NaN (*)) is not undefined behaviour.
>
> Although that's how typical implementations behave, the C standard says
> that copying from a source variable has undefined beha
Is this patch necessary? The elements of the structure are initialized
prior to the return statement.
Since the `i`, `j`, and `count` are not really used, I feel like the SAST
report I've sent can be marked as a false positive.
Do you agree?
On Sat, Aug 17, 2024 at 7:17 AM Paul Eggert wrote:
>
1 - 100 of 3321 matches
Mail list logo
