[asterisk-dev] channel_walk_locked possible bug / possible fix?

[Steve Davies]

On 11/17/06, Kevin P. Fleming <kpfleming at digium.com> wrote:
> Steve Davies wrote:
> > The reason I made the observation about name_prefix searching is
> > because all of the name/prefix matches are inside an
> >  if(!prev) {...}
> > block, which will never evaluate to true because the name_prefix
> > searching method provides a value for prev.
>
> You are absolutely correct... the only time the name/namelen or
> context/exten matching is done is for the first channel that is found,
> after that we just return all channels. This is clearly wrong.
> Apparently there is no code that is trying to use the API calls in that
> way, but it's obviously wrong.

Just a comment on the new 1.2 BRANCH version of this code. If 'prev'
and 'name' are both provided, the function will only return a locked
channel if the named channel is the one immediately after prev, is
that the intended behaviour, or should it search from prev+1 to the
end of the list for 'name'

I assume the latter, which is why in my other patch I broke the
channel loop into 2 chunks. The 1st to get to 'prev' if specified, and
the second to scan all of the remaining channels in the list for the
supplied conditions.

As you say, nothing actually uses this combination so it is low
priority. I will include this change in my revised patch.

(Disclaimer has been sent, so bug can be updated to reflect this)

Cheers,
Steve