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

Previous Next

Full log

View this message in rfc822 format

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: bug#13472: [PATCH] libtool: speed up by pre-cutting sed's input by dd
Date: Thu, 13 Feb 2014 18:57:21 +0100

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?

I.e. keep func_lalib_p as before:

func_lalib_p ()
{
    test -f "$1" &&
      $SED -e 4q "$1" 2>/dev/null \
        | $GREP "^# Generated by .*$PACKAGE" > /dev/null 2>&1
}

but change func_ltwrapper_script_p from:

func_ltwrapper_script_p ()
{
    func_lalib_p "$1"
}

into:

func_ltwrapper_script_p ()
{
    test -f "$1" &&
      $lt_truncate_bin < "$1" 2>/dev/null \
        | $GREP "^# Generated by .*$PACKAGE" > /dev/null 2>&1
}

where lt_truncate_bin is either "/usr/bin/dd bs=4096 count=1" or
"$SED -e 4q" depending on the presence of a suitable dd.

That way we shave off a fork, which can't be bad...

Thoughts? Or should I just push out the prior patch?

Cheers,
Peter

Previous Next

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