<div dir="ltr">On Fri, May 17, 2013 at 2:14 PM, Richard Mudgett <span dir="ltr"><<a href="mailto:rmudgett@digium.com" target="_blank">rmudgett@digium.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">> I'm working on a fairly invasive set of fixes that apply to 1.8. It<br>
> would be really handy to be able to use RAII_VAR there since I<br>
> intend to submit the same fix for 11 and trunk, as well.<br>
><br>
><br>
> Is there any reason we can't include RAII_VAR in 1.8?<br>
><br>
> The only reason I can think of is some OS versions have old compilers<br>
> that do not support the gcc feature used for RAII_VAR.<br>
> CentOS comes to mind.<br>
><br>
><br>
> It is the greatest thing since sliced bread...<br>
><br>
> I do know that when we added it, we had at least one bug report from<br>
> someone who was using clang to compile Asterisk. We opted not to<br>
> remove<br>
> RAII_VAR, but at least at the time 11 was new, and they still had 1.8<br>
> to<br>
> use.<br>
><br>
> Backporting it to 1.8 midstream would be a hard stop to anyone<br>
> attempting to compile Asterisk with anything other than gcc - which<br>
> is,<br>
> admittedly, unsupported.<br>
><br>
> I don't think that's a show-stopper, but it is probably the largest<br>
> risk<br>
> that I can think of. I'm personally fine with it, but at least wanted<br>
> to<br>
> note that before you went ahead and did it.<br>
><br>
> A better question would be, would you backport it into certified<br>
> asterisk too?<br>
><br>
> I'm always against backporting to a release branch, simply because we<br>
> never can fully predict the results. That said, I'm still at<br>
> 1.8.7.1, so as long as we expect bug reports to happen and we<br>
> address any regressions with higher priority, but that is just my<br>
> opinion.<br>
><br>
><br>
> The size of this backport is tiny. It's a small macro. It's just<br>
> incredibly useful and actually helps write code less likely to<br>
> contain errors.<br>
><br>
><br>
> If it's a problem, it shouldn't be *too* hard to pull it back out.<br>
> The difficultly comes with however many places you have started<br>
> using it. In my case, it's in the SLA code, so it's a pretty small<br>
> fraction of the code base. If it gets backported, explodes through<br>
> the 1.8 code, and then a problem is found 6 months later, that would<br>
> be much more painful. I wouldn't expect it to spread too fast in<br>
> 1.8, since the changes are intentionally minimal. It just might make<br>
> fixing some bugs easier.<br>
><br>
><br>
> Compiler version impact is worth considering. I don't know what the<br>
> specific impact is in terms of distro support, though. How about we<br>
> assume it's ok, and if there's an uproar, I agree to do the work to<br>
> revert the usage I added.<br>
<br>
</div></div>You should also backport ao2_cleanup() which was created for use with<br>
RAII_VAR to tolerate NULL pointers.<br>
<br>
void ao2_cleanup(void *obj)<br>
{<br>
if (obj) {<br>
ao2_ref(obj, -1);<br>
}<br>
}<br></blockquote><div><br></div><div style>Good call. Thanks.</div><div style><br></div><div style>I had a temporary equivalent helper in app_meetme.c for now, but I guess it makes sense to backport the general one.</div>
<div style><br></div><div style>-- </div><div style>Russell Bryant </div></div></div></div>