[asterisk-dev] backport RAII_VAR to 1.8?

[Richard Mudgett]

> 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);
  }
}

Richard