tdb_chainlock() in tdb1, tdb2 and tdb_compat ?

Volker Lendecke Volker.Lendecke at SerNet.DE
Fri Apr 13 02:02:37 MDT 2012

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.

I was already asked to create the notify patches for 3.6,
and I am reluctant to put them into 3.6 without having them
in master first. If you want me to do that, I can certainly
do it. But this would be a major improvement that goes into
3.6 that master does not see.

Please tell me how waf solves this.



SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen, mailto:kontakt at

More information about the samba-technical mailing list