tridge at samba.org
tridge at samba.org
Tue Jul 28 06:35:49 MDT 2009
> But only when the code is exercised in particular circumstances.
no, it finds every case where the semantics have changed.
> We can never be sure that this covers all cases in a finite amount of
> time, or that we get the notices in all the failures. It's not
> definitely reliable.
yes, we can be sure, as the only ways in which the behaviour has
changed is in ways that produce a warning. If a warning is not
produced then the semantics haven't changed. If you think I'm wrong on
this then please provide an example.
> Your approach was successful only in that it completed, but I don't find
> the results more attractive than what they replace.
> The large code base is a red herring, it just takes more time.
no, it isn't a red herring.
When we change semantics in Samba we usually try to change the
function form, so the compiler catches the error. We can't do that in
this case in any reasonable way. The alternative is to print a clear
warning when a call is made where the semantics differs from the
previous semantics. That is what the patch tried to do.
> Either you want me to provide a way of auditing the code that we both
> think doesn't exist... or we don't agree on what definitely reliable means.
If you want to propose these changes to go in then you need to take
seriously the existing codebase that relied on the existing
semantics. That is not something that can be just ignored.
> Because we don't rigorously declare functions that take ownership, we
> don't have the information we need to audit the code automatically.
> We also need to use human reasoning to work out what the buggy code
> should have been.
not so. As the patches I've made show, it is possible to make changes
in a way that is safe. I'm just finding it rather frustrating to have
to explain this so many times. Go and look at your patches and see if
you can find a way to make the change you want safely. If you can then
we can look at the semantics you propose.
More information about the samba-technical