Re: [PATCH 1/2] [vcs-to-changelog] Split ProjectQuirks out into its own file

On 8/20/20 1:44 PM, Paul Eggert wrote: > Thanks, I installed those patches into Gnulib and added the corresponding > ChangeLog patches. Thanks for fixing this! -- Cheers, Carlos.

Re: [PATCH] Add renameat2 function [BZ #17662]

On 07/04/2018 04:26 PM, Florian Weimer wrote: > On 07/04/2018 10:13 PM, Carlos O'Donell wrote: >> This is a good suggestion, and I think Florian should work on >> something going into the manual to document the behaviour. > > We do not have any documentation for the *a

Re: [PATCH] Add renameat2 function [BZ #17662]

On 07/04/2018 03:35 PM, Paul Eggert wrote: > Carlos O'Donell wrote: > >> If we really need another non-race-free API then gnulib can provide >> that. > > We do really need it. All existing uses of renameat2-like > functionality in GNU applications already use t

Re: [PATCH] Add renameat2 function [BZ #17662]

On 07/04/2018 05:04 AM, Andreas Schwab wrote: > On Jul 03 2018, Paul Eggert wrote: > >> Florian Weimer wrote: >>> Surely that's a gnulib bug because the main reason for the >>> RENAME_NOREPLACE variant renameat2 was to avoid exactly that race (or >>> the other race where the file exists under bot

Re: [PING] [PATCH 00/17] Regex: Make libc regex more usable outside GLIBC

On 12/19/2017 11:42 AM, arn...@skeeve.com wrote: > I do appreciate that the trend is to merge with gnulib; that will > ultimately be a good thing so I am encouraged by it. I just committed the obvious comment fixes into glibc. I expect Paul to commit something similar to gnulib and that way we wo

Re: [PATCH 01/17] Regex: Fix spelling errors / typos.

On 12/19/2017 02:03 PM, Paul Eggert wrote: > These typo changes are all in Gnulib, and would be fine to install in glibc. > > Adding bug-gnulib to the CC list. For reference, the original email is here: > https://sourceware.org/ml/libc-alpha/2017-12/msg00243.html Done. I've pushed these for Arnol

Re: [PATCH] Initialize the entire obstack struct [BZ #17919]

On 02/03/2015 01:14 PM, Carlos O'Donell wrote: > On 02/03/2015 12:05 PM, Siddhesh Poyarekar wrote: >> On Tue, Feb 03, 2015 at 11:49:26AM -0500, Carlos O'Donell wrote: >>> IMO zero-initialized padding, for this case, isn't something you can >>> exp

Re: [PATCH] Initialize the entire obstack struct [BZ #17919]

On 02/03/2015 12:05 PM, Siddhesh Poyarekar wrote: > On Tue, Feb 03, 2015 at 11:49:26AM -0500, Carlos O'Donell wrote: >> IMO zero-initialized padding, for this case, isn't something you can >> expect. Therefore I think it's a compiler bug. > > Thanks, I've

Re: [PATCH] Initialize the entire obstack struct [BZ #17919]

On 02/03/2015 11:46 AM, Andreas Schwab wrote: > Siddhesh Poyarekar writes: > >> This is also why I started out filing a gcc bug, but then changed my >> mind and fixed it in glibc instead, since I presumed that the compiler >> can assume that the padding is also appropriately initialized. > > No,

Re: [PATCH] Initialize the entire obstack struct [BZ #17919]

On 02/03/2015 11:38 AM, Siddhesh Poyarekar wrote: > [Also looping in bug-gnulib] > > On Tue, Feb 03, 2015 at 11:30:17AM -0500, Carlos O'Donell wrote: >> Is this a valgrind bug, false positive in valgrind, or bug in glibc? >> >> It clearly says we have a move that

Re: [PATCH 2/2] regex: test for buffer overrun

On 03/31/2013 11:11 AM, Nix wrote: > On 30 Jan 2013, Paul Eggert spake thusly: > >> + /* This test is from glibc bug 15078. >> + The test case is from Andreas Schwab in >> + >>

Re: remove.m4 test

ger override on all platforms. Fixes bug from 2012-03-20. > * m4/remove.m4 (gl_FUNC_REMOVE): Test gl_cv_func_unlink_honors_slashes, > not gl_cv_func_unlink_works. > Reported by Carlos O'Donell . Thank you Bruno! Cheers, Carlos. -- Carlos O'Donell Mentor Graph