Paolo Bonzini wrote:
> I'm undecided whether it's better to talk about dates, or rather say
> "2.6.27 to 2.6.29"
Why not both? Applied:
--- doc/posix-functions/dup2.texi.orig 2009-08-26 01:46:07.0 +0200
+++ doc/posix-functions/dup2.texi 2009-08-26 01:45:35.0 +0200
@@ -22,7
On Tue, 25 Aug 2009, Eric Blake wrote:
> Another solution is for the application to sanitize all newly-created
> fds: GNU coreutils provides a wrapper open_safer, which does nothing
> extra in the common case that open() returned 3 or larger, but calls
> fcntl(n,F_DUPFD,3)/close(n) before returnin
Many applications have subtle bugs if started with one or more of the
STD*_FILENO file descriptors closed; although this is an uncommon
case, it should be considered during security audits. For example, an
attempt to write a message to stderr during 'cp a b >&- 2>&-' in a
naive implementation of '
Indeed. This is a Linux bug that affects only 64-bit kernels. It was
introduced in July 2008
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.30.y.git;a=commitdiff;h=6c5d0512a091480c9f981162227fdb1c9d70e555
and only fixed in May 2009
http://git.kernel.org/?p=linux/kernel/git/stabl
Eric Blake writes:
> According to Simon Josefsson on 8/24/2009 2:49 PM:
>> Simon Josefsson writes:
>>
>>> test-pipe.c:79: assertion failed
>>> test-pipe.sh: iteration 4 failed
>>> test-pipe.c:79: assertion failed
>>> test-pipe.sh: iteration 5 failed
>>> test-pipe.c:79: assertion failed
>>> test
Hi Jim,
> I have no control over glibc's error, and it uses program_invocation_name,
> not program_invocation_short_name, so in order to make diagnostics appear like
>
> program_name:
>
> rather than
>
> /abs/dir.../.libs/lt-program_name:
>
> the set_program_name function mus
Eric Blake wrote:
> > These tests fails the same way on a Debian x86 system (the gcc compile
> > farm host "gcc60") as well, see:
> >
> > http://autobuild.josefsson.org/gnulib/log-20090823221435536.txt
>
> That log also shows that test-dup2.c and test-popen.sh are failing; it
> appears all of
Sergey Poznyakoff wrote:
>> +#if HAVE_DECL_PROGRAM_INVOCATION_NAME
>> + program_invocation_name = (char *) argv0;
>> +#endif
>
> In my opinion, that's not correct. Libc (and gnulib's argp, FWIW) uses
> two variables: program_invocation_name, which points to the full program
> name as obtained fro
Hello,
> +#if HAVE_DECL_PROGRAM_INVOCATION_NAME
> + program_invocation_name = (char *) argv0;
> +#endif
In my opinion, that's not correct. Libc (and gnulib's argp, FWIW) uses
two variables: program_invocation_name, which points to the full program
name as obtained from argv[0], and program_inv
Bruno Haible wrote:
>> +2009-08-24 Jim Meyering
>> +
>> +progname: also set global program_invocation_name, when possible
>> +Before this change, a libtool-enabled program that calls glibc's
>> +error function would report the program name as
>> +"/abs/dir/.libs/lt-program_name"
On 08/25/2009 02:27 AM, Bruno Haible wrote:
Simon Josefsson wrote:
no objection from me.
OK, I've added the module and applied the support for old kernels:
Thanks!
Paolo
11 matches
Mail list logo