Re: [RFC PATCH] explicitly mark recursion count

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

On Wed, 2 June 2004 09:25:50 -0700, Linus Torvalds wrote:
> 
> Well, multiple recursion around the same function seems to be solvable two 
> different ways:
>  - "don't do that then". It really seems broken, but maybe there are 
>    really really good reasons _why_ it's not broken and why it happens.
>  - make sure that the separate loops are broken in some _other_ place than 
>    in the function they share.
> 
> A combination of the two may work well.
> 
> I say "may", because maybe I'm wrong, and the condition is common and hard
> to avoid limiting in the shared function. I don't have your data (and I'm
> lazy, so quite frankly I'd much rather you do the analysis anyway ;).

You *do* have my data, but I buy the lazy argument. ;)

> That said, I just don't see any sane alternatives to my "break in one
> place" thing. I believe that anything more complex that tries to explain
> the whole loop is just going to be a nightmare to maintain, and fragile as
> hell except for totally static legacy code that nobody touches any more.

Amen, brother.  Anything complicated will contain bugs tomorrow, if
not already today.

Let's see.  Right now, we have two cases of multiple recursions:
WARNING: multiple recursions around check_sig()
WARNING: multiple recursions around usb_audio_recurseunit()

check_sig() is bad code and can be cleaned up.

Leaves usb_audio_recurseunit() as the only function in question, that
one could actually be sane, although it looks rather interesting:
WARNING: trivial recursion detected:
       0  usb_audio_recurseunit
WARNING: recursion detected:
      16  usb_audio_selectorunit
       0  usb_audio_recurseunit
WARNING: multiple recursions around usb_audio_recurseunit()
WARNING: recursion detected:
       0  usb_audio_recurseunit
       0  usb_audio_processingunit

Greg, can you say whether this construct makes sense?

Jörn

-- 
Eighty percent of success is showing up.
-- Woody Allen