On Fri, 2004-01-23 at 20:16, Greg Hudson wrote:
> 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.
Fair enough.
> > > 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.
None of that work requires memory allocation. It's walking a list
and returns true/false depending on whether there are conflicts/diffs.
> > 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.
I guess you're right. I have to say I don't really like yet another
type, especially something with a hairy history as off_t. But if it is
the right thing to do.
Sander
---------------------------------------------------------------------
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:47:06 2004