[asterisk-dev] [Code Review] Force consistency for ast_realtime_load_multientry when no rows are returned

[wdoekes]

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

Ship it!


+1

- wdoekes


On Oct. 12, 2011, 8:54 p.m., Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1521/
> -----------------------------------------------------------
> 
> (Updated Oct. 12, 2011, 8:54 p.m.)
> 
> 
> Review request for Asterisk Developers, Tilghman Lesher and wdoekes.
> 
> 
> Summary
> -------
> 
> config.h does not document what ast_realtime_load_multientry should return in the case of no results being returned. Several backends return an empty ast_config. This has caused at least one error in chan_sip where a non-NULL result was assumed to mean that there were results returned. After discussions on IRC, it was agreed that returning NULL for no results made sense and resulted in simpler code. Instead of hunting down the inconsistencies in each backend, this patch destroys empty ast_configs and returns NULL inside the API call.
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/include/asterisk/config.h 340521 
>   /branches/1.8/main/config.c 340521 
> 
> Diff: https://reviewboard.asterisk.org/r/1521/diff
> 
> 
> Testing
> -------
> 
> I ran my SIP realtime tests and verified that the incorrect conditional branch was no longer taken. I also looked at every usage of ast_load_realtime_multientry to verify that a NULL result for no rows would be safe. It is. Every call checks for NULL and none look like they would behave differently. Every place just iterates over the results (except the call in chan_sip which tested NULL as a test for "no results").
> 
> 
> Thanks,
> 
> Terry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111013/416528a5/attachment.htm>