tdb_chainlock() in tdb1, tdb2 and tdb_compat ?

[Rusty Russell]

On Fri, 13 Apr 2012 10:02:37 +0200, Volker Lendecke <Volker.Lendecke at SerNet.DE> wrote:
> On Fri, Apr 13, 2012 at 05:24:30PM +1000, Andrew Bartlett wrote:
> > On Fri, 2012-04-13 at 08:07 +0200, Volker Lendecke wrote:
> > 
> > > Back to the original question that started this thread: Does
> > > symbol versioning also solve the TDB_ERROR vs int return
> > > problem I saw? How does waf guarantee that from within code
> > > that is not properly converted yet we do not call
> > > tdb_chainlock that returns TDB_ERROR but the int version
> > > from tdb1? This to me is much more serious because the
> > > compiler does not catch it as an error as it does with
> > > tdb_fetch.
> > 
> > I think Rusty would be best placed to describe his work here once he
> > returns from his Honeymoon, but I do know he spent a lot of time
> > ensuring that before tdb2 was enabled in the top level that all users
> > were converted away from checking errors with == -1.  (Loosing the work
> > done there was the bit-rotting I was concerned about if we dropped tdb2
> > for 4.0, as you proposed on IRC).
> 
> You did not answer the question how waf ensures we never
> call the wrong tdb_chainlock function. I think manual
> inspection here is not sufficient. I need to understand the
> mechanism because I need to add a tdb_chainlock_nonblock
> function, and I need to know where I need to put the int
> version and where I need to put the TDB_ERROR version.

We remove TDB1.  Then we always call tdb2, and there is no ambiguity.

Perhaps my temerity in the switch-over is to blame for the confusion
here.

Cheers,
Rusty.