Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

Sorry for the delayed response; I've been offline for a couple of weeks. On Sat, Jul 05, 2025 at 01:31:22AM +0200, Alejandro Colomar wrote: > Hi Eric, > > On Fri, Jun 20, 2025 at 01:38:14AM +0200, Alejandro Colomar wrote: > > > > - POSIX.1-2001 > > > > > > This one defers to C89

Re: bug#79072: install -d onto readonly fs prints the wrong error

Thanks for reporting that inaccurate diagnostic. Sorry about the tricky code; it's a tricky situation. Looks like Collin's patch is not quite right. I installed the attached patches into Gnulib. The first one fixes the two cases you mentioned, the second an unlikely bug I discove

Re: [PATCH] listxattr: document Linux 6.15 bug

Pádraig Brady writes: > Excellent. I updated the bug with that info: > https://bugzilla.redhat.com/2369561 Thanks! I forgot that I should do that... > The issue wasn't in the wild long enough really so > to warrant any more workarounds. Agreed. Collin

Re: [PATCH] listxattr: document Linux 6.15 bug

64 I don't think it is a big deal, but perhaps I overestimate how many people run 'dnf update' frequently. Collin [1] https://bodhi.fedoraproject.org/updates/FEDORA-2025-7feed8b25a Excellent. I updated the bug with that info: https://bugzilla.redhat.com/2369561 I generally upda

Re: [PATCH] listxattr: document Linux 6.15 bug

Pádraig Brady writes: > Various gnulib acl tests breaking (on fedora 42 for example) is problematic. > > For my ref one can work around the issue by pointing TMPDIR away from tmpfs > like: > > TMPDIR=/foo/bar make check > > I was considering skipping the tests if on tmpfs with kernel 6.1[45],

Re: [PATCH] listxattr: document Linux 6.15 bug

On 17/06/2025 17:12, Paul Eggert wrote: This bug should be fixed in Linux kernel 6.16; see: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fe78e02600f83d81e55f6fc352d82c4f264a2901 For what it's worth, Coreutils decided not to work around the bug, and inste

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

Hi Eric, On Sat, Jul 05, 2025 at 01:31:38AM +0200, Alejandro Colomar wrote: > > > > - POSIX.1-2001 > > > > > > This one defers to C89 anywhere that it is not explicitly documenting > > > with CX shading. > > > > Ahh, I had thought it would defer to C99 because it's older, but I

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

Hi Collin, On Sat, Jul 05, 2025 at 02:44:02AM +0200, Alejandro Colomar wrote: > > You can look for yourself here, . Hmmm, I've only found definitions, but no uses at all. All definitions seem to be there for compatibility with SysV. I wonder what SysV had

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

Hi Collin, On Fri, Jul 04, 2025 at 05:15:27PM -0700, Collin Funk wrote: > Alejandro Colomar writes: > > > BTW, I was trying to find out the history of memccpy(3), and why it was > > introduced in 4.4BSD. Does anyone know the history? I find it a weird > > function that doesn't have any good us

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

Alejandro Colomar writes: > BTW, I was trying to find out the history of memccpy(3), and why it was > introduced in 4.4BSD. Does anyone know the history? I find it a weird > function that doesn't have any good use case, or I don't seem to see it. > Every use case I see, such as a poor-man's str

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

Hi Eric, On Fri, Jun 20, 2025 at 01:38:14AM +0200, Alejandro Colomar wrote: > > > - POSIX.1-2001 > > > > This one defers to C89 anywhere that it is not explicitly documenting > > with CX shading. > > Ahh, I had thought it would defer to C99 because it's older, but I guess > it's like

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

> Em 21 de jun. de 2025, à(s) 09:12, Sam James escreveu: > > Alejandro Colomar writes: > >> Hi Sam, >> >>> On Sat, Jun 21, 2025 at 04:57:32AM +0100, Sam James wrote: >>> Alejandro Colomar writes: >>> [...] But the glibc maintainers mentioned that they're investigating abo

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

Hi Adhemerval, Florian, On Sat, Jun 21, 2025 at 12:14:59PM -0300, Adhemerval Zanella wrote: > (assuming he had some consensus em fixing it). I think now we are somewhat > far from it… It would be good if the few people that still disagree, such as Florian, would comment on the proposal, which I

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

Hi Sam, On Sat, Jun 21, 2025 at 04:57:32AM +0100, Sam James wrote: > Alejandro Colomar writes: > > > [...] > > > > But the glibc maintainers mentioned that they're investigating about it > > in distros, so I guess we'll eventually have the results of their > > investigation. > > > > To manage e

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

Alejandro Colomar writes: > Hi Sam, > > On Sat, Jun 21, 2025 at 04:57:32AM +0100, Sam James wrote: >> Alejandro Colomar writes: >> >> > [...] >> > >> > But the glibc maintainers mentioned that they're investigating about it >> > in distros, so I guess we'll eventually have the results of their

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

Alejandro Colomar writes: > [...] > > But the glibc maintainers mentioned that they're investigating about it > in distros, so I guess we'll eventually have the results of their > investigation. > To manage expectations: I haven't seen anyone say they're going to work on this. I recall Sid menti

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

On 2025-06-20 09:30, Eric Blake wrote: I am less certain without more research whether the wording that Andreas was referring to at the time the feature knob was switched made it into the approved C99 unchanged, or if that was still undergoing debates in the C committee. As I understand it Andr

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

On Fri, 20 Jun 2025, Mark Harris wrote: > There were three editions of POSIX prior to POSIX.1-2001: Also the Trial-Use 1986 edition. (Appendix D, Comparison with Related Systems, marks realloc with "**", where "Functions marked ** are considered to be included in this standard by reference to

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

Hi Eric, On Fri, Jun 20, 2025 at 11:30:59AM -0500, Eric Blake wrote: > On Fri, Jun 20, 2025 at 01:37:58AM +0200, Alejandro Colomar wrote: > > Hey Eric! > > > > Thanks a lot for the detailed reply! Comments below. > > Ditto. > [...] > > See

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

(s) were being floated around, in order to > > try and make it so that glibc would not have to change behavior, but > > at the same time trying to make it possible for applications to be > > able to make wise runtime decisions on how to use realloc that would > > not leak memor

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

Hi Vincent, On Fri, Jun 20, 2025 at 04:36:31PM +0200, Vincent Lefevre wrote: > > So, the input pointer must not be freed. > > Yes, this is what I mentioned in interpretation 1 above (so with > memory leaks in practice, as applications call realloc(non_null,0) > to free memory, while memory will n

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

On 2025-06-20 13:58:23 +0200, Alejandro Colomar wrote: > On Fri, Jun 20, 2025 at 04:11:23AM +0200, Vincent Lefevre wrote: > > You should also consider the end of 7.20.3p1 (which applies to calloc, > > malloc and realloc): > > > > If the size of the space requested is zero, the behavior is > >

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

edition/functions/realloc.html POSIX.1-2013 = POSIX.1-2008 + TC1; TC1 includes the POSIX changes to realloc from bug 400. https://austingroupbugs.net/view.php?id=400 https://open-std.org/JTC1/SC22/WG14/www/docs/dr_400.htm - Mark

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

Hi Vincent, On Fri, Jun 20, 2025 at 04:11:23AM +0200, Vincent Lefevre wrote: > On 2025-06-20 01:37:58 +0200, Alejandro Colomar wrote: > > On Thu, Jun 19, 2025 at 01:31:06PM -0500, Eric Blake wrote: > > > On Wed, Jun 18, 2025 at 09:04:02PM +0200, Alejandro Colomar wrote: > > > > glibc doesn

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

On 2025-06-19 22:55:32 -0700, Paul Eggert wrote: > Thanks for the detailed summary. Here are a few more details. In this > summary "realloc(p,0)" assumes p is nonnull. > > As I understand it: > > (a) These guarantees are for compatibility with glibc 2.2+. In older glibc > versions realloc(p,0) be

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

On 2025-06-19 11:31, Eric Blake wrote: glibc folks are aware that realloc(non_null, 0) has two useful behaviors, and that glibc picks the behavior that does NOT behave consistently with malloc(0), because of back-compat guarantees: Thanks for the detailed summary. Here are a few more details.

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

On 2025-06-20 01:37:58 +0200, Alejandro Colomar wrote: > On Thu, Jun 19, 2025 at 01:31:06PM -0500, Eric Blake wrote: > > On Wed, Jun 18, 2025 at 09:04:02PM +0200, Alejandro Colomar wrote: > > > glibc doesn't conform to: > > > - SysIII > > > - SysV > > > - SysVr2 >

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

> glibc and Bionic are non-conforming to POSIX.1-2024. The fix > > > > > > > that we're > > > > > > > proposing would make them conforming. Does conformance to > > > > > > > POSIX.1-2024 > > > > > > > mean somet

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

posing would make them conforming. Does conformance to > > > > > > POSIX.1-2024 > > > > > > mean something to you? > > > > > > > > > > not when POSIX screwed up and made a change that made most of the > > > > > existing imple

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

glibc and Bionic are non-conforming to POSIX.1-2024. The fix that > > > > > we're > > > > > proposing would make them conforming. Does conformance to > > > > > POSIX.1-2024 > > > > > mean something to you? > > > > > &

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

mean something to you? > > > > > > not when POSIX screwed up and made a change that made most of the > > > existing implementations non-conformant, no. that sounds like a POSIX > > > bug to me... > > Not most. Only two POSIX implementations, plus Windows. An

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

and Bionic are non-conforming to POSIX.1-2024. The fix that we're > > > proposing would make them conforming. Does conformance to POSIX.1-2024 > > > mean something to you? > > > > not when POSIX screwed up and made a change that made most of the > > existing i

Re: BUG: realloc(p,0) should be consistent with malloc(0)

Hi Andreas, On Wed, Jun 18, 2025 at 05:42:40PM +0200, Andreas Schwab wrote: > On Jun 17 2025, Alejandro Colomar wrote: > > > RETURN VALUE > > > > If size is 0, > > ... > > either: > > > > - A null pointer shall be returned > >and, if ptr is not

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

ing. Does conformance to POSIX.1-2024 > > mean something to you? > > not when POSIX screwed up and made a change that made most of the > existing implementations non-conformant, no. that sounds like a POSIX > bug to me... > > (like i said, i care greatly about actual sh

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

On Wed, Jun 18, 2025 at 11:37 AM Thorsten Glaser wrote: > > On Wed, 18 Jun 2025, enh wrote: > > >not when POSIX screwed up and made a change that made most of the > >existing implementations non-conformant, no. that sounds like a POSIX > > “most of”? ...weighted by number of users (who could be n

Re: BUG: realloc(p,0) should be consistent with malloc(0)

On Jun 17 2025, Alejandro Colomar wrote: > RETURN VALUE > > If size is 0, > ... > either: > > - A null pointer shall be returned >and, if ptr is not a null pointer, >errno shall be set to EINVAL. > > - A pointer to t

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

On Wed, 18 Jun 2025, enh wrote: >not when POSIX screwed up and made a change that made most of the >existing implementations non-conformant, no. that sounds like a POSIX “most of”? Looks to me like most implementations already do the latter, and some might do the former, and only a minority (the

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

X screwed up and made a change that made most of the existing implementations non-conformant, no. that sounds like a POSIX bug to me... (like i said, i care greatly about actual shipping code. a standard is interesting for green-field stuff, but when it's at odds with reality it's ofte

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

nd the implementations (you) refuse to > > > > accept the fix until the committee standardizes something, then we'll > > > > have the problem forever. > > > > > > is it really a problem though? you're basically asking to _add_ an > > > i

Re[2]: [musl] Re: BUG: realloc(p, 0) should be consistent with malloc(0)

And folks who do know aren't complaining that it's broken, because the behavior is currently conforming just bad. Rather they're tiptoeing around the issue by special-casing zero and making sure they never pass zero to realloc, or wrapping it to do that, etc. Anecdotal data point: it's exactly

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

oblem forever. > > > > > > is it really a problem though? you're basically asking to _add_ an > > > incompatibility with existing versions of glibc/bionic (so, you know, > > > "basically every non-Windows computer out there"). > > >

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

t; incompatibility with existing versions of glibc/bionic (so, you know, > > "basically every non-Windows computer out there"). > > > > from my perspective: > > > > pros: > > + code would then behave the same on android and ios > > cons: &g

[PATCH] listxattr: document Linux 6.15 bug

This bug should be fixed in Linux kernel 6.16; see: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fe78e02600f83d81e55f6fc352d82c4f264a2901 For what it's worth, Coreutils decided not to work around the bug, and instead to suggest updating to a fixed kernel or

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

know, > "basically every non-Windows computer out there"). > > from my perspective: > > pros: > + code would then behave the same on android and ios > cons: > - code would behave differently on different versions of android > - code would behave differently on

Re: BUG: realloc(p,0) should be consistent with malloc(0)

On Mon, Jun 16, 2025 at 5:44 PM Alejandro Colomar wrote: > > Hi Florian, > > On Mon, Jun 16, 2025 at 09:35:01PM +0200, Florian Weimer wrote: > > * Adhemerval Zanella Netto: > > > > > I have re-read the whole thread and it seems that most maintainers are OK > > > with this change and agree that cur

Re: BUG: realloc(p,0) should be consistent with malloc(0)

> ? what does Windows do? There's quite a bit of documentation: My favorite part is actually this: | realloc hasn't been updated to implement C17 behavior because the new | behavior isn't compatible with t

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

On 2025-06-17 07:51, Rich Felker wrote: I'm not sure what you mean by "not having heard anyone but you bring this up in the last 15 years". This has been a recurring issue +1. One thing I kinda would like to think about is if there's a way we can signal at compile-time (without run tests th

Re: BUG: realloc(p,0) should be consistent with malloc(0)

On Mon, 16 Jun 2025, Alejandro Colomar wrote: > Since glibc and Bionic are the two implementations that are currently > broken, could you please fix your implementations? I'm sure the > C Committee will be much easier to convince if the implentations have > changed in a clear direction. > > But

Re: BUG: realloc(p,0) should be consistent with malloc(0)

Hi Joseph, On Mon, Jun 16, 2025 at 11:39:48PM +, Joseph Myers wrote: > On Mon, 16 Jun 2025, Alejandro Colomar wrote: > > > Since glibc and Bionic are the two implementations that are currently > > broken, could you please fix your implementations? I'm sure the > > C Committee will be much ea

Re: BUG: realloc(p,0) should be consistent with malloc(0)

rned non-null. The BSD line kept this behavior, while SysV eventually moved to returning a null pointer, in what seems a documentation bug that eventually degenerated into the actual behavior. Regardless of the result of malloc(0) in the descendents of the

Re: BUG: realloc(p,0) should be consistent with malloc(0)

Hi Florian, On Mon, Jun 16, 2025 at 09:35:01PM +0200, Florian Weimer wrote: > * Adhemerval Zanella Netto: > > > I have re-read the whole thread and it seems that most maintainers are OK > > with this change and agree that current POSIX's realloc spec has some > > drawbacks (albeit it still allow

Re: BUG: realloc(p,0) should be consistent with malloc(0)

Hi Elliott, On Mon, Jun 16, 2025 at 12:40:18PM -0400, enh wrote: > On Mon, Jun 16, 2025 at 7:55 AM Alejandro Colomar wrote: > > > > Hi! > > > > For context, the old discussion was in this thread: > >

Re: BUG: realloc(p,0) should be consistent with malloc(0)

On 16/06/25 16:35, Florian Weimer wrote: > * Adhemerval Zanella Netto: > >> I have re-read the whole thread and it seems that most maintainers are OK >> with this change and agree that current POSIX's realloc spec has some >> drawbacks (albeit it still allows current glic behavior). >> >> The

Re: BUG: realloc(p,0) should be consistent with malloc(0)

* Adhemerval Zanella Netto: > I have re-read the whole thread and it seems that most maintainers are OK > with this change and agree that current POSIX's realloc spec has some > drawbacks (albeit it still allows current glic behavior). > > The only one involved in the previous thread that raised

Re: BUG: realloc(p,0) should be consistent with malloc(0)

On 16/06/25 08:55, Alejandro Colomar wrote: > Hi! > > For context, the old discussion was in this thread: > > > Also for context, here's the excellent research by наб about malloc(0) > an

Re: [musl] BUG: realloc(p,0) should be consistent with malloc(0)

On 2025-06-16 05:24, Rich Felker wrote: Do you have numbers for how many packages have actually pulled in the updated gnulib and shipped with it? With this change, do you have it replacing realloc on glibc, so that the new realloc actually gets used? I would expect yes; I don't have numbers, bu

Re: BUG: realloc(p,0) should be consistent with malloc(0)

On Mon, Jun 16, 2025 at 7:55 AM Alejandro Colomar wrote: > > Hi! > > For context, the old discussion was in this thread: > > > Also for context, here's the excellent research by наб about mal

Re: [musl] BUG: realloc(p,0) should be consistent with malloc(0)

Hi Rich, Paul, Bruno, On Mon, Jun 16, 2025 at 08:24:15AM -0400, Rich Felker wrote: > > This was done in > > > > d884e6fc4a60 (2024-11-03, 2024-11-04; "realloc-posix: realloc (..., 0) > > now returns nonnull") > > > > After more than half a year of changing the behavior in gnulib, there > >

Re: [musl] BUG: realloc(p,0) should be consistent with malloc(0)

On Mon, Jun 16, 2025 at 01:55:26PM +0200, Alejandro Colomar wrote: > Hi! > > For context, the old discussion was in this thread: > > > Also for context, here's the excellent research by наб

BUG: realloc(p,0) should be consistent with malloc(0)

Hi! For context, the old discussion was in this thread: Also for context, here's the excellent research by наб about malloc(0) and realloc(p, 0) in historic UNIX systems and their descendent

Re: parse-datetime bug on NetBSD 10.0

On 6/10/25 19:39, Collin Funk wrote: [1]https://austingroupbugs.net/view.php?id=1614 Although that's related, it's a precursor to the discussion that I vaguely recall. And the fix that it proposes (which I don't see in POSIX.1-2024) isn't right either. It's a real mess.

Re: parse-datetime bug on NetBSD 10.0

Hi Paul, Paul Eggert writes: > Yes, this is an iffy area in the mktime spec. I installed the attached > further coreutils patch to try to avoid the iffy area. Thanks, the test passes with that patch. I guess non-existent times due to daylight savings were probably an after thought when writing

Re: parse-datetime bug on NetBSD 10.0

10 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Problem reported by Collin Funk in: https://lists.gnu.org/r/bug-gnulib/2025-06/msg00094.html * tests/date/date-debug.sh: Also allow NetBSD 10 mktime behavior. Although NetBSD contradicts POSIX, POSIX is

Re: parse-datetime bug on NetBSD 10.0

Hi Paul, Paul Eggert writes: > On 2025-06-08 17:39, Collin Funk wrote: >> Posting on bug-gnulib since this test failure seems to be caused by >> parse-datetime despite being caught by tests/date/date-debug.sh in >> Coreutils. > > I installed the attached patch to

Re: parse-datetime bug on NetBSD 10.0

that platform [1]. Ah, good. I didn't know that you had already collected the infos and eliminated the possibility of an arch-specific bug. Bruno

Re: parse-datetime bug on NetBSD 10.0

On 2025-06-08 17:39, Collin Funk wrote: Posting on bug-gnulib since this test failure seems to be caused by parse-datetime despite being caught by tests/date/date-debug.sh in Coreutils. I installed the attached patch to Gnulib, along with a minor testcase patch in Coreutils. Please give it a

Re: parse-datetime bug on NetBSD 10.0

Bruno Haible writes: >> Posting on bug-gnulib since this test failure seems to be caused by >> parse-datetime despite being caught by tests/date/date-debug.sh in >> Coreutils. >> >> On NetBSD 10.0 (cfarm428.cfarm.net) it fails with the following: > > This

Re: parse-datetime bug on NetBSD 10.0

Hi Collin, > Posting on bug-gnulib since this test failure seems to be caused by > parse-datetime despite being caught by tests/date/date-debug.sh in > Coreutils. > > On NetBSD 10.0 (cfarm428.cfarm.net) it fails with the following: This is a NetBSD 10.0/arm64 machine. What ab

parse-datetime bug on NetBSD 10.0

Hi, Posting on bug-gnulib since this test failure seems to be caused by parse-datetime despite being caught by tests/date/date-debug.sh in Coreutils. On NetBSD 10.0 (cfarm428.cfarm.net) it fails with the following: + returns_ 1 date --debug -d 'TZ="America/Edmonton" 2006

[PATCH] listxattr: document Linux 6.14- bug

This bug is fixed in Linux kernel 6.15; see: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8b0ba61d For what it's worth, Coreutils decided not to work around the bug, and instead to suggest updating to a fixed kernel. --- doc/glibc-functions/flistxattr.tex

Re: bug#77800: grep-3.12: write-error-msg test failure on fedora rawhide (f43)

On Mon, Apr 21, 2025 at 12:20 AM Jaroslav Škarvada wrote: > > $ { env printf %4095s; env printf %4096s; } > /dev/full > > printf: write error: Broken pipe > > printf: write error > > > Guys, thanks for the analysis and quick actions. BTW is the Fedora > help patch which uncovered this

havelib: Fix m4 underquoting bug in AC_LIB_FROMPACKAGE

the $3 in this macro invocation chain. Adding one or two levels of additional m4 quotes fixes this. 2025-05-04 Bruno Haible havelib: Fix m4 underquoting bug in AC_LIB_FROMPACKAGE. Reported for GNU clisp by Adam Sampson at <https://gitlab.com/gnu-clisp

Re: bug#50098: Configuring --with-libsigsegv results in link error

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

Re: bug#77800: grep-3.12: write-error-msg test failure on fedora rawhide (f43)

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

Re: bug#77800: grep-3.12: write-error-msg test failure on fedora rawhide (f43)

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

Re: bug#77800: grep-3.12: write-error-msg test failure on fedora rawhide (f43)

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

Re: bug#77800: grep-3.12: write-error-msg test failure on fedora rawhide (f43)

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

Re: bug#77800: grep-3.12: write-error-msg test failure on fedora rawhide (f43)

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

Re: bug#77800: grep-3.12: write-error-msg test failure on fedora rawhide (f43)

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

Re: bug#77800: grep-3.12: write-error-msg test failure on fedora rawhide (f43)

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

Re: bug#77800: grep-3.12: write-error-msg test failure on fedora rawhide (f43)

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

Re: bug#77800: grep-3.12: write-error-msg test failure on fedora rawhide (f43)

; > 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

select tests: Work around a Cygwin bug

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. *

Re: vasnprintf tests: Add a test case that showcases a Solaris 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

*printf: Document a Haiku bug

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. *

Re: vasnprintf tests: Add a test case that showcases a Solaris bug

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

vasnprintf tests: Add a test case that showcases a Solaris bug

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

getlocalename_l-unsafe: Work around Cygwin 3.6.0 bug

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

Re: bug#76876: logname output is often wrong when linked with glibc

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

Re: bug#76876: logname output is often wrong when linked with glibc

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

Re: futimens: Work around a GNU/Hurd bug.

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

futimens: Work around a GNU/Hurd bug.

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

Re: utimensat: Work around a GNU/Hurd bug.

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

Re: utimensat: Work around a GNU/Hurd bug.

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

utimensat: Work around a GNU/Hurd bug.

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

Re: bug#76876: logname output is often wrong when linked with glibc

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.

Re: bug#76876: logname output is often wrong when linked with glibc

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

Re: bug#76876: logname output is often wrong when linked with glibc

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

bug#76876: logname output is often wrong when linked with glibc

> Password: > # logname > bruno > > Paul, Pádraig: How about adding a coreutils/NEWS entry for this bug fix? > > Bruno > > > > > >

Re: bug#76876: logname output is often wrong when linked with glibc

$ su - Password: # logname bruno Paul, Pádraig: How about adding a coreutils/NEWS entry for this bug fix? Bruno

  1   2   3   4   5   6   7   8   9   10   >