GNU bug report logs - #13472
Execution mode can hang pc when parameter refers to big file

Previous Next

Full log

Message #77 received at 13472 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Nick Bowler <nbowler <at> draconx.ca>
Cc: Pavel Raiskup <pavel <at> raiskup.cz>, 13472 <at> debbugs.gnu.org
Subject: Re: bug#13472: [PATCH] libtool: speed up by pre-cutting sed's input
 by dd
Date: Thu, 13 Feb 2014 20:52:59 +0100

[Message part 1 (text/plain, inline)]

On 2014-02-13 18:57, Peter Rosin wrote:
> On 2014-02-12 16:22, Nick Bowler wrote:
>> On 2/11/14, Peter Rosin <peda <at> lysator.liu.se> wrote:
>>> Ok Pavel, first of all, sorry for the "smallish" delay in handling
>>> your request, and Nick, are you able to test this patch?
>> [...]
>>> Does my version work? The testsuite behaves OK for me, but other than
>>> that I haven't tested.
>>
>> Patch seems to work!
> 
> Ok, everybody seems happy. But not me, not 100% anyway. This introduces
> an extra fork, and AFAICT, the "extra protection" is only needed when
> func_lalib_p is called from func_ltwrapper_script_p. Should we perhaps
> have a separate implementation in func_ltwrapper_script_p instead of
> simply calling func_lalib_p?
> 
> Maybe we could also lose the "sed -e 4q" part when dd limits the size?

*snip* outline, real patch attached instead...

Now, which patch should I push?

The old [1]:
libtool: speed up lalib detection in execute mode

or the new?
libtool: speed up ltwrapper_script detection in execute mode

I like the latter better and will push that soonish. Unless...

Cheers,
Peter

[1] http://lists.gnu.org/archive/html/bug-libtool/2014-02/msg00005.html

[0001-libtool-speed-up-ltwrapper_script-detection-in-execu.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.