[asterisk-dev] [Code Review] 3557: odbc: Remove fixed size buffers.

wdoekes reviewboard at asterisk.org
Tue May 27 06:53:41 CDT 2014


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3557/#review11969
-----------------------------------------------------------

Ship it!



/branches/1.8/funcs/func_odbc.c
<https://reviewboard.asterisk.org/r/3557/#comment21881>

    For consistency add a *query=NULL here.


Looks good to me.

Fire away!

- wdoekes


On May 27, 2014, 11:07 a.m., Joshua Colp wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3557/
> -----------------------------------------------------------
> 
> (Updated May 27, 2014, 11:07 a.m.)
> 
> 
> Review request for Asterisk Developers and wdoekes.
> 
> 
> Bugs: ASTERISK-23582
>     https://issues.asterisk.org/jira/browse/ASTERISK-23582
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This change removes fixed size buffers in ODBC related code for reading in row data and func_odbc configuration. For func_odbc the configured queries are duplicated instead of being stored in a fixed size buffer. For dynamic realtime a thread local strings is enlarged as needed as row data is read in. For static realtime the maximum size of a configuration value is read in and buffer created accordingly.
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/res/res_config_odbc.c 414555 
>   /branches/1.8/funcs/func_odbc.c 414555 
> 
> Diff: https://reviewboard.asterisk.org/r/3557/diff/
> 
> 
> Testing
> -------
> 
> Configured func_odbc within MySQL (via ODBC) using extconfig with a 3000 length query and configured it was read in completely. This used static realtime and func_odbc.
> Configured chan_sip to use peers stored in MySQL (via ODBC) and stored very long values. Confirmed read in completely.
> 
> Also ran these scenarios under valgrind to confirm no memory insanity.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140527/b7afcc9f/attachment-0001.html>


More information about the asterisk-dev mailing list