[QUICK] talloc bugs

[Jeremy Allison]

On Wed, Jul 01, 2009 at 08:27:38AM -0400, simo wrote:
> On Wed, 2009-07-01 at 22:12 +1000, tridge at samba.org wrote:
> > Hi Simo,
> > 
> >  > In any case I'd like to stress we need to maintain ABI compatibility, so
> >  > whatever the decision I think we need still quite some work on what was
> >  > currently committed (possibly with a revert first).
> > 
> > To justify that please point me at a valid use of talloc that was in
> > our tree that the change broke. 
> > 
> > The change affected code that was already ambiguous. Ambiguous code is
> > something we always want to avoid, and we should not be preserving
> > ambiguous APIs.
> > 
> > Regarding the ABI, yes I broke that as talloc_free was a function and
> > is now a macro.

I don't think we can do this. We need to keep the ABI stable
for external users just like we do with libsmbclient.

For internal Samba uses we can change the code to call
any function we like - doing a global change to the
merged Samba tree to use a different function name is
preferable to breaking the external ABI. I think talloc_free()
has to remain an external function, we should call something
else if we can to do something different. That's one of
the advantages of the TALLOC_FREE macro we usually use,
we can change everything easily.

> It's not just talloc_free(), you changed the signature of
> _talloc_steal() and _talloc_reference(), see the talloc.signature file
> Standalone talloc is incidentally broken now of course (talloc.exports
> for details).
> 
> >  That means a recompile. Has talloc usage outside of
> > Samba really grown to the point where a recompile is unacceptable?
> 
> Yes, in fedora alone even evolution depends on talloc through
> openchange. Openchange itself may be broken by this change too of
> course.

This to me is the main point. We have large external projects
that depend on talloc. There are cases where changing the external
ABI and bumping the version number is appropriate (talloc.so.2), but this
(IMHO) is not one of them. We wouldn't do this with libsmbclient,
I don't think we can do this with talloc.

We can't depend on packagers to get this right. It won't be done
correctly.

> No, it's not *a* person, there are libraries that depend on talloc, so
> it is a chain of dependencies that is quite big.
> The only way to solve the problem, would be to fork talloc, but I think
> the changes made are not important enough to warrant a fork.

I agree. It would be a shame to have to fork talloc over this
bugfix, which is a very neccessary fix (IMHO). Can't we find a
way to do this without arbitrarily changing the ABI ? Do we
know of any users of talloc_reference outside of Samba ?

Jeremy.