Re: Handling of the slow path: why do we do it this way?

On Wed, Oct 7, 2009 at 5:10 PM, Paul Smith <[email protected]> wrote:
> Sorry for more email.
>
> I've been looking at the code in job.c that handles the slow path, and I
> don't understand why it's being done the way it is.

Funny you bring this up now because I've just been stumbling around in
that area and wondering the exact same thing. It seems like a rare
example of an inelegant recursive algorithm, though I just assumed I
hadn't figured out the logic yet.

BTW, what I ended up with for .ONESHELL was almost exactly what you
describe - once I find myself in the slow path (i.e. at the "slow:"
label) I skip the whole recursion concept, allocate an argv of size 4,
assign SHELL, .SHELLFLAGS, <recipe>, and NULL to those 4 elements, and
return. It's been working fine, though of course I don't have to split
<recipe> into lines, and there are many corner conditions yet
unexplored.

I'll send out my current patch for context. It contains a long
temporary comment listing remaining issues.

-David