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

[Joshua Colp]

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



/branches/1.8/res/res_config_odbc.c
<https://reviewboard.asterisk.org/r/3557/#comment21862>

    After using as a buffer you can call ast_str_update to update the internal string length value, and thus not require using strlen.


- Joshua Colp


On May 22, 2014, 2:53 p.m., Joshua Colp wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3557/
> -----------------------------------------------------------
> 
> (Updated May 22, 2014, 2:53 p.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 414399 
>   /branches/1.8/funcs/func_odbc.c 414399 
> 
> 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/20140522/682d1f35/attachment.html>