Eric Blake wrote:
> According to Jim Meyering on 12/4/2009 12:52 PM:
>> If you don't mind, sending git format-patch output
>> (i.e with a log entry) and removing the space-before-TAB ^^
>> would be nice.
>
> I went ahead and did the grunt work, this time around. Now pushed.
Thanks!
> commit f921
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 12/4/2009 12:52 PM:
>
> Thanks. That looks fine.
> If you don't mind, sending git format-patch output
> (i.e with a log entry) and removing the space-before-TAB ^^
> would be nice.
I went ahead and did the grunt work, th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Pádraig Brady on 12/4/2009 7:14 PM:
>>> Why does the first element get extra checks.
>>> Is it more likely to be duplicated?
>> Yes, for two reasons. One, we pre-insert an arbitrary gid_t to the front..
>> Two, some OS's actually list the
Eric Blake wrote:
> Think about the *_safer modules. ... invoke execve without the child process
> having fd 0, 1, and 2 properly set.
This case is different, because here the child process can run for a long time
without experiencing a problem. Whereas a NULL pointer either leads to a crash
or
Eric Blake wrote:
> According to Pádraig Brady on 12/4/2009 6:20 PM:
>>> + /* Remove pair-wise duplicates, as well as any duplicate of the
>> ? + first element. Rather than do a full O(n log n) duplicate
>>> + removal, this only visits the most common duplicates. */
>> Why does the first
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Pádraig Brady on 12/4/2009 6:20 PM:
>> + /* Remove pair-wise duplicates, as well as any duplicate of the
> ? + first element. Rather than do a full O(n log n) duplicate
>> + removal, this only visits the most common duplicates.
Eric Blake wrote:
> The first was a bug I introduced when moving mgetgroups from coreutils to
> gnulib (comparing a gid_t with -1 will fail on platforms where gid_t is
> uint16_t; the coreutils version only used the gid argument in the getugroups
> case, so the bug came from my new code for the
Bruno Haible clisp.org> writes:
> > While that usage of execve is in violation of POSIX
>
> One of the purposes of specifications is to avoid redundant checking
> of arguments.
But this is NOT redundant.
> It makes sense to be "lenient in what you accept", for example when the
> spec is unclea
Bruno Haible wrote:
> Hi Jim,
>
>> Ok to apply the patch below?
>> Without it, anyone can make nearly any coreutils program segfault
>> with this simple recipe:
>>
>> printf '%s\n' '#include ' 'int main(int c, char**v)' \
>> '{ execve (v[1], 0, 0); }' > k.c && gcc k.c && ./a.out /bin/cat
Hi all, this is an experiment in adding a pure DFA matcher to gnulib.
The code is basically taken from regexec.c, but butchered to eliminate
registers and backreferences (3000 lines of code less...). I started
it just after looking at the depressing list of bugs in GNU grep's
dfa.c. Since deletin
Hi Jim,
> Ok to apply the patch below?
> Without it, anyone can make nearly any coreutils program segfault
> with this simple recipe:
>
> printf '%s\n' '#include ' 'int main(int c, char**v)' \
> '{ execve (v[1], 0, 0); }' > k.c && gcc k.c && ./a.out /bin/cat
>
> While that usage of execv
On Fri, Dec 4, 2009 at 7:48 PM, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to James Youngman on 12/4/2009 11:36 AM:
>> * find/pred.c (file_sparseness): Use -1.0*HUGE_VAL rather than
>> -HUGE_VAL to avoid compilation error on Solaris x86_64. This
>> avoids a
The first was a bug I introduced when moving mgetgroups from coreutils to
gnulib (comparing a gid_t with -1 will fail on platforms where gid_t is
uint16_t; the coreutils version only used the gid argument in the getugroups
case, so the bug came from my new code for the getgroups case). I didn't
On Fri, Dec 04, 2009 at 07:01:37AM -0700, Eric Blake wrote:
One failure case is indeed errno==ENOSYS. (By the way, which system did
you find this on?)
Found on a custom embedded Linux server.
if mgetgroups doesn't find any groups, "groups" will not be changed and
therefore still contain an u
Alfred M. Szmidt wrote:
> In inetutils we use something like `Version 1.6 (2008-12-27):' in
> NEWS, but news-date-check hardcodes it, and expects something else, `*
> FOO 1.6 (2008-12-27)', would this be acceptable for overriding the
> format?
>
> diff --git a/top/maint.mk b/top/maint.mk
> index c3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to James Youngman on 12/4/2009 11:36 AM:
> * find/pred.c (file_sparseness): Use -1.0*HUGE_VAL rather than
> -HUGE_VAL to avoid compilation error on Solaris x86_64. This
> avoids a "wrong type argument to unary minus" compiler error.
> * NEWS
Alfred M. Szmidt gnu.org> writes:
>
> In inetutils we use something like `Version 1.6 (2008-12-27):' in
> NEWS, but news-date-check hardcodes it, and expects something else, `*
> FOO 1.6 (2008-12-27)', would this be acceptable for overriding the
> format?
Seems reasonable to me; while it is nic
Eric Blake wrote:
> I'd like to push this as the fix. However, it would be nicer to credit a
> full name, rather than just "Scott", for listing you in THANKS.
The fix looks fine, thanks.
whois says it's: Scott Harrison
cheers,
Pádraig.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding gnulib, since mgetgroups now lives in gnulib]
According to scott.gnu.2...@scottrix.co.uk on 12/4/2009 3:55 AM:
> All,
>
> In coreutils 8.1, src/id.c line 296:
>
> gid_t *groups;
> int i;
>
> int n_groups = mgetgroups (usernam
Hi Bruno,
Ok to apply the patch below?
Without it, anyone can make nearly any coreutils program segfault
with this simple recipe:
printf '%s\n' '#include ' 'int main(int c, char**v)' \
'{ execve (v[1], 0, 0); }' > k.c && gcc k.c && ./a.out /bin/cat
While that usage of execve is in violat
20 matches
Mail list logo
