In gnulib commit 7b1de4a62f876:
commit 7b1de4a62f8766787160f785217671b074e0f0f2
Author: Bruno Haible
Date: 2020-04-10 15:57:10 +0200
findprog, relocatable-prog: Ignore directories during PATH search.
Reported by Frederick Eaton via Dmitry Goncharov in
Asher and all - the CC-BY-ND (or, previously, "verbatim copying is
allowed") is intended to refer to the web page as posted publicly
(that's why it's visible text), not the gendocs_* template files
themselves.
I suppose there should be commented-out text stating the license of the
template text,
Paul Eggert wrote:
> > to gnulib, in a file doc/nstrftime.texi?
>
> And have coreutils.texi include that? Sure, that should work. I suppose
> there'd be a new Gnulib package for the nstrftime documentation?
It doesn't even need an extra Gnulib module. For 'parse-datetime', we have
added the
On 5/21/20 2:08 PM, Bruno Haible wrote:
So, how about moving the sections [1]
Time conversion specifiers
Date conversion specifiers
Literal conversion specifiers
Padding and other flags
to gnulib, in a file doc/nstrftime.texi?
And have coreutils.texi include that? Sure, that should
Hi Paul,
> Given that the coreutils manual's 'date' section already documents the
> nstrftime format, perhaps the least-work approach would be to change the
> Gnulib nstrftime comments/documentation to point to the coreutils manual.
Still, that would mean that someone who makes a change to
Paul Eggert wrote:
> > - Should glibc define SA_RESETHAND as ((int)0x8000) ?
> >Then SA_RESETHAND could not be used in preprocessor directives any more.
>
> POSIX would allow that, as it doesn't require SA_RESETHAND to be usable
> in preprocessor directives. However, too much software
On 5/21/20 6:40 AM, Bruno Haible wrote:
I don't think the coreutils 'date' documentation is or should be
the reference manual for nstrftime().
Hmm, well, to some extent I might prefer just one copy of the
documentation for those formats, either in the 'date' manual or in an
'nstrftime'
On 5/21/20 8:15 AM, Bruno Haible wrote:
- Should glibc define SA_RESETHAND as ((int)0x8000) ?
Then SA_RESETHAND could not be used in preprocessor directives any more.
POSIX would allow that, as it doesn't require SA_RESETHAND to be usable
in preprocessor directives. However, too much
Hi Tim,
These comparisons are not so useful, because they not only come from different
compilers (gcc vs. clang) but also from systems with different libcs: there
are differences regarding libm, calloc, thrd_create, pthread_sigmask, and other
functions. It would be more useful to compare, on the
> > Yes, the looser license for my contributions makes sense.
>
> Same here. Thanks.
Thanks for your approvals. Done:
2020-05-21 Bruno Haible
group-member: Relicense under LGPLv2+.
Jim Meyering's approval is in
Paul Eggert wrote:
> > - if (memmem (haystack, 3, NULL, 0) != haystack)
> > + if (memmem (haystack, 3, (const char *) 1, 0) != haystack)
>
> This has undefined behavior in general, no?
No. memmem is not supposed to access more than NEEDLELEN bytes at NEEDLE.
> How about using '""'
On 5/21/20 11:40 AM, Bruno Haible wrote:
- if (memmem (haystack, 3, NULL, 0) != haystack)
+ if (memmem (haystack, 3, (const char *) 1, 0) != haystack)
This has undefined behavior in general, no? So some future sanitizer may
complain about it, for good reason.
How about using '""'
On 5/21/20 7:22 AM, Bruno Haible wrote:
Can you agree to relicensing it under LGPLv2+?
Yes, that's fine.
Tim Rühsen wrote:
> configure:36833: checking whether memmem works
> SUMMARY: UndefinedBehaviorSanitizer: invalid-null-argument
This patch should fix it.
2020-05-21 Bruno Haible
memmem: Avoid wrong configure results with "clang -fsanitize=undefined".
Reported by Tim Rühsen
Tim Rühsen wrote:
> configure:94107: checking for working re_compile_pattern
> SUMMARY: AddressSanitizer: 20072 byte(s) leaked in 116 allocation(s).
This patch should fix it.
2020-05-21 Bruno Haible
regex: Avoid wrong configure results with "clang -fsanitize=leak".
Reported
Tim Rühsen wrote:
> configure:67322: checking whether glob lists broken symlinks
> SUMMARY: AddressSanitizer: 37 byte(s) leaked in 2 allocation(s).
This patch should fix it.
2020-05-21 Bruno Haible
glob: Avoid wrong configure results with "clang -fsanitize=leak".
Reported by
Tim Rühsen wrote:
> configure:55268: checking whether fchownat works with AT_SYMLINK_NOFOLLOW
> SUMMARY: UndefinedBehaviorSanitizer: implicit-integer-sign-change
> conftest.c:812:50 in
> configure:55326: checking whether fchownat works with an empty file name
> SUMMARY: UndefinedBehaviorSanitizer:
Tim Rühsen reports:
> configure:14038: checking for working C stack overflow detection
> SUMMARY: UndefinedBehaviorSanitizer: implicit-integer-sign-change
Here's a reduced test case:
$ cat foo.c
#include
int
main ()
{
struct sigaction act;
act.sa_flags = /* SA_NODEFER | SA_ONSTACK | */
On Thu, May 21, 2020 at 7:44 AM Eric Blake wrote:
> On 5/21/20 9:22 AM, Bruno Haible wrote:
> > Hi Jim, Paul, Eric,
> >
> > You are the contributors of the module 'group-member', which is under
> > GPLv3+.
> > Can you agree to relicensing it under LGPLv2+?
> >
> > Rationale:
> >
> > The
On 5/21/20 9:22 AM, Bruno Haible wrote:
Hi Jim, Paul, Eric,
You are the contributors of the module 'group-member', which is under GPLv3+.
Can you agree to relicensing it under LGPLv2+?
Rationale:
The 'euidaccess' module, which is under LGPLv2+, needs to use this module
(for portability to
> The attached patch fixes it. (Please feel free to amend.)
Thanks, I've pushed it in your name.
Bruno
Hi Tim,
> With my getdelim patch applied, this is the summary of sanitizer findings:
>
> $ egrep 'SUMM|checking' config.log|grep -B1 SUMM
> configure:14038: checking for working C stack overflow detection
> SUMMARY: UndefinedBehaviorSanitizer: implicit-integer-sign-change
> conftest.c:379:30 in
Hi Tim,
> > You may try to pass '--avoid=gettext' to overcome this.
>
> ./configure --config-cache ends (stops ?) with
> The BISON_I18N macro is used without being preceded by AM_GNU_GETTEXT.
Oh well. Then you apparently need '--avoid=gettext --avoid=bison-i18n'.
> And I see this output here
Hi Jim, Paul, Eric,
You are the contributors of the module 'group-member', which is under GPLv3+.
Can you agree to relicensing it under LGPLv2+?
Rationale:
The 'euidaccess' module, which is under LGPLv2+, needs to use this module
(for portability to many platforms). Currently gnulib-tool emits
Hi Paul,
> > If the change is intended, the documentation of `date` should be updated
>
> Thanks for mentioning this. The change was intended, and I installed the
> attached patch into the Coreutils documentation.
Where is %N of nstrftime documented? I don't see it documented in POSIX [1],
in
On Thursday, May 21, 2020 2:35:12 AM CEST Paul Eggert wrote:
> On 5/20/20 10:51 AM, Kamil Dudka wrote:
> > If the change is intended, the documentation of `date` should be updated
>
> Thanks for mentioning this. The change was intended, and I installed the
> attached patch into the Coreutils
26 matches
Mail list logo
