tdb_chainlock() in tdb1, tdb2 and tdb_compat ?

[Michael Adam]

Hi folks,

Volker Lendecke 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.
> 
> 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.

I understand that there is a real problem with the
sublte difference in signature and return semantics for
tdb_chainlock.

There can always be new callers that check == -1 instead of < 0,
so I think the best way would have been to have a compat
version for these, too, so that the difference is explicit.

I also think simo's proposal was quite reasonable,
but the middle course might be to consequently use the compat
layer for such functions as chainlock for which the compiler does
not complain about differences (at least the C compiler...).

For the demand of samba3 still being able to link against
system libtdb (version 1.X), couldn't we introduce tdb into
libreplace and do some #define trickts? ...

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120413/71955142/attachment.pgp>