[asterisk-dev] bweschke: branch 1.4 r150816 - /branches/1.4/main/manager.c

[BJ Weschke]

Russell Bryant wrote:
> On Oct 17, 2008, at 8:42 PM, SVN commits to the Digium repositories  
> wrote:
>
>   
>> Author: bweschke
>> Date: Fri Oct 17 20:42:23 2008
>> New Revision: 150816
>>
>> URL: http://svn.digium.com/view/asterisk?view=rev&rev=150816
>> Log:
>> Using the GetVar handler in AMI is potentially dangerous (insta- 
>> crash [tm]) when you use a dialplan function that requires a channel  
>> and then you don't provide one or provide an invalid one in the  
>> Channel: parameter. We'll handle this situation exactly the same way  
>> it was handled in pbx.c back on r61766. We'll create a bo
>> gus channel for the function call and destroy it when we're done. If  
>> we have trouble allocating the bogus channel then we're not going to  
>> try executing the function call at all and run the risk of crashing.
>>     
>
>
> I do not have a direct problem with this change, because it is the  
> correct thing to do if dialplan functions are allowed to assume a  
> channel is present.
>
> However, I'd like to propose that for the sake of performance, we  
> handle this the opposite way.  How about we make it so that dialplan  
> functions are _not_ allowed to assume that a channel will be present.   
> For any function that _must_ have a channel to do something useful  
> (like the CHANNEL() function!), just make it return an error if no  
> channel is provided.
>
> Thoughts?
>
>   
 
 When we talk about "the sake of performance" it really comes down to 
where the performance hit actually is, no ?

 With the current patch, we only take on the hit on performance on the 
execution of a manager GetVar action when it's determined that the 
varname is likely a function. If we move this logic into the guts of 
ast_func_read proper, isn't that a much larger creep on the scope of 
that performance hit?

-- 
--
Bird's The Word Technologies, Inc.
http://www.btwtech.com/