On Fri, 2004-01-23 at 13:55, Sander Striker wrote:
> > It was discussed on IRC this afternoon if we should remove the need for
> > the pool param to svn_io_file_seek (which we could do) or should add a
> > pool param to diff. The consensus of those who responded was to add
> > pool to diff.
>
> Well, no. If you need a pool in any of the functions you put in
> your callback tables: svn_diff_fns_t or svn_diff_output_fns_t,
> put it in the private baton you pass into the svn_diff_diff* or
> svn_diff_output call.
Requiring callbacks to use the baton to get at a pool is not consistent
with our other callback interfaces, and tends to encourage (though not
mandate) memory leaks.
> > On the diff issue I changed more of the interfaces than probably
> > necessary. If svn_diff_contains_conflicts and svn_diff_contains_diffs
>
> Those are read only functions and will never need a pool.
What does being read-only have to do with needing a pool? You need a
pool if any of the work you're doing requires memory allocation, whether
or not that memory is interesting to the caller.
> How on earth did we get ourselves into this mess?
We used apr_off_t without realizing the ramifications. It's not really
our fault, but it is our problem.
> Isn't it easier to 'fix Perl' as Joe Orton suggests on dev@apr, which seems the
> biggest motivator for this change, and be done with it?
APR can't solve the problem on our time scale. If we don't eliminate
our use of apr_off_t (for now), and APR changes the size of apr_off_t,
then we will be stuck at APR 0.9 for the entire lifetime of svn 1.x. I
don't think that's a very palatable situation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 23 20:17:33 2004