On Wed, Aug 6, 2014 at 10:59 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Wed, Aug 06, 2014 at 08:15:44PM -0000, stefan2_at_apache.org wrote:
> > Author: stefan2
> > Date: Wed Aug 6 20:15:43 2014
> > New Revision: 1616338
> > URL: http://svn.apache.org/r1616338
> > Log:
> > Beautify bits of the hotcopying code.
> > * subversion/libsvn_fs_fs/fs.c
> > (uninitialize_fs_struct): New utility function.
> > (fs_hotcopy): Use that new function to make the init/uninit symmetry
> > more obvious and add more commentary.
> > Modified:
> > subversion/trunk/subversion/libsvn_fs_fs/fs.c
> > Modified: subversion/trunk/subversion/libsvn_fs_fs/fs.c
> > URL:
> > --- subversion/trunk/subversion/libsvn_fs_fs/fs.c (original)
> > +++ subversion/trunk/subversion/libsvn_fs_fs/fs.c Wed Aug 6 20:15:43
> > @@ -245,6 +245,16 @@ initialize_fs_struct(svn_fs_t *fs)
> > return SVN_NO_ERROR;
> > }
> > +/* Reset vtable and fsap_data fields in FS such that the FS is basically
> > + * closed now. Note that FS must not hold locks when you call this. */
> > +static svn_error_t *
> > +uninitialize_fs_struct(svn_fs_t *fs)
> I'd suggest to declare this as:
> static void
> uninitialize_fs_struct(svn_fs_t *fs)
Thanks for the review.
You are right, I might change that to plain void but I'll keep
the error return type for now, just for symmetry with the init
code. This is also a function that might have actual error
conditions in later releases and a missed caller update would
than create an error leak (and probably worse).
Received on 2014-08-11 18:35:37 CEST