LDB hidden memory leaks

[Kamen Mazdrashki]

Hi Tridge,

On Mon, Jul 12, 2010 at 05:35, <tridge at samba.org> wrote:

> Hi Kamen,
>
>  > > Alternatives I can see are:
>  > > ldm_msg_canonicalize_2
>  > > ldb_msg_canonicalize_ex
>  > > ldb_msg_canonicalize_p (as in parent)
>
> If you're going to change the name, and deprecate the old one, then
> just choose a new name. eg. ldb_msg_normalize().
>
> For ldb_msg_diff(), we can use ldb_msg_difference()
>
>
Won't it be easier for users of those functions to understand,
that it is same functionality with different interface by just
adding a suffix to already existing function names?
Anyway, I don't care that much about function names
(I am having difficulties naming functions every time I have to).
What I care about is the interface. So if you feel functions
should have different names, I will rename them.


Speaking of interfaces, I wanted to discuss something
that bothers me pretty much lately - it is how memory
context are passed when calling functions.

For example, imagine I read following code:
    *struct ldb_val new_val = ldb_val_dup(el->values, &values[j]);*
It is clear it duplicates values[j] object.
But what we pass el->values for?
Perhaps it duplicate values[j] and add it to el->values collection, right?
After looking at ldb_val_dup() prototype, I see that el->values
is used as a TALLOC_CTX actually.
On the other hand, if I read something like
    *struct ldb_val new_val = ldb_val_dup((TALLOC_CTX*)el->values,
&values[j]);*
then it is clear el->values is just a memory context.

So, my question is (are):
1. what do you thing about enforcing TALLOC_CTX casting to be explicit?
2. and if everyone agrees it is 'good thing', then is it feasible to force
    callers to explicitly cast pointers to TALLOC_CTX* where used?

-- 
CU,
Kamen