<div dir="ltr">On Fri, May 17, 2013 at 1:35 PM, Paul Belanger <span dir="ltr"><<a href="mailto:paul.belanger@polybeacon.com" target="_blank">paul.belanger@polybeacon.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="im">On 13-05-17 01:22 PM, Matthew Jordan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 05/17/2013 10:46 AM, Richard Mudgett wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
</blockquote>
<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>
</blockquote>
<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 remove<br>
RAII_VAR, but at least at the time 11 was new, and they still had 1.8 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 is,<br>
admittedly, unsupported.<br>
<br>
I don't think that's a show-stopper, but it is probably the largest risk<br>
that I can think of. I'm personally fine with it, but at least wanted to<br>
note that before you went ahead and did it.<br>
<br>
</blockquote></div>
A better question would be, would you backport it into certified asterisk too?<br>
<br>
I'm always against backporting to a release branch, simply because we never can fully predict the results. That said, I'm still at 1.8.7.1, so as long as we expect bug reports to happen and we address any regressions with higher priority, but that is just my opinion.</blockquote>
<div><br></div><div style>The size of this backport is tiny. It's a small macro. It's just incredibly useful and actually helps write code less likely to contain errors.</div><div><br></div><div style>If it's a problem, it shouldn't be *too* hard to pull it back out. The difficultly comes with however many places you have started using it. In my case, it's in the SLA code, so it's a pretty small fraction of the code base. If it gets backported, explodes through the 1.8 code, and then a problem is found 6 months later, that would be much more painful. I wouldn't expect it to spread too fast in 1.8, since the changes are intentionally minimal. It just might make fixing some bugs easier.</div>
<div style><br></div><div style>Compiler version impact is worth considering. I don't know what the specific impact is in terms of distro support, though. How about we assume it's ok, and if there's an uproar, I agree to do the work to revert the usage I added.</div>
<div style><br></div><div style>-- </div><div style>Russell Bryant</div></div></div></div>