[asterisk-dev] backport RAII_VAR to 1.8?

Russell Bryant russell at russellbryant.net
Fri May 17 13:18:59 CDT 2013


On Fri, May 17, 2013 at 2:14 PM, Richard Mudgett <rmudgett at digium.com>wrote:

> > I'm working on a fairly invasive set of fixes that apply to 1.8. It
> > would be really handy to be able to use RAII_VAR there since I
> > intend to submit the same fix for 11 and trunk, as well.
> >
> >
> > Is there any reason we can't include RAII_VAR in 1.8?
> >
> > The only reason I can think of is some OS versions have old compilers
> > that do not support the gcc feature used for RAII_VAR.
> > CentOS comes to mind.
> >
> >
> > It is the greatest thing since sliced bread...
> >
> > I do know that when we added it, we had at least one bug report from
> > someone who was using clang to compile Asterisk. We opted not to
> > remove
> > RAII_VAR, but at least at the time 11 was new, and they still had 1.8
> > to
> > use.
> >
> > Backporting it to 1.8 midstream would be a hard stop to anyone
> > attempting to compile Asterisk with anything other than gcc - which
> > is,
> > admittedly, unsupported.
> >
> > I don't think that's a show-stopper, but it is probably the largest
> > risk
> > that I can think of. I'm personally fine with it, but at least wanted
> > to
> > note that before you went ahead and did it.
> >
> > A better question would be, would you backport it into certified
> > asterisk too?
> >
> > 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.
> >
> >
> > 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.
> >
> >
> > 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.
> >
> >
> > 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.
>
> You should also backport ao2_cleanup() which was created for use with
> RAII_VAR to tolerate NULL pointers.
>
> void ao2_cleanup(void *obj)
> {
>   if (obj) {
>     ao2_ref(obj, -1);
>   }
> }
>

Good call.  Thanks.

I had a temporary equivalent helper in app_meetme.c for now, but I guess it
makes sense to backport the general one.

-- 
Russell Bryant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130517/85e22598/attachment.htm>


More information about the asterisk-dev mailing list