Greg Hudson <ghudson@MIT.EDU> writes:
> This is true of essentially every function we have which takes a pool,
> and of essentially every object we have which contains a pool. Why
> document it for every function? Should we also document what pools are
> and how they work, for every function?
I would say yes, we should document it for every function, as we do
elsewhere in Subversion. There are, or have been, objects in
Subversion which contain pool references where the pool's lifetime is
longer than the objects. These are usually batons, not entries, but
you get the point.
But it's not a big enough concern for me to complain further about it,
beyond answering your question, nor to do anything about it.
Obviously, the answer to your rhetorical second question is "No" :-).
> > In the first case, in editor.c, the next call, to
> > ds->editor->delete_entry(), used 'entry->pool' too. But here, the
> > next call, also ds->editor->delete_entry(), uses 'pool' instead.
>
> Both should be using pool. The only reason to use entry->pool is if
> you're creating an object which is going to live in the entry.
>
> The discrepancy is because editorp.c (the code which normally gets used)
> was fixed, while editor.c (the pre-0.34 compatibility code) was not.
Thanks. Peter, you want to take care of this?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 29 20:42:30 2004