5.2-rel, route.c question

While looking at rtalloc1 in depth, trying to figure out the recursive
lock Peter mailed here a little while ago, I noticed something unrelated
about rtalloc1 I was hoping someone could explain to me.

At route.c:161 (cvs vers 1.92.2.1), I notice that it locks the rt pointer
it plans on returning, but does not inc the reference count.

The other two execution paths of rtalloc1 both lock & inc the ref
count.

And later, in rtrequest1 (route.c:784), a call to rtalloc1 is made, and
in one case RTFREE_LOCKED(rt) is used, in the other rtexpunge is used
which looks safe to me either way.

but...

IFF rtalloc1 did not RT_ADDREF(), AND rtrequest1 RTFREE_LOCKED()'s it,
then will the rt not be freed out from under the other reference?  And
badness can then ensue?


I'm hoping someone more familiar with the code can tell me I'm wrong.
I've never read a line of it until today, so it's probable I'm just
confused.

-- 
David W. Hankins		"If you don't do it right the first time,
					you'll just have to do it again."
						-- Jack T. Hankins