On Mon, Jan 23, 2006 at 06:21:49PM +0000, Philip Martin wrote:
> > The ones I didn't fix were:
> >
> >> subversion/libsvn_diff/diff_file.c: In function
> >> 'svn_diff__file_output_unified_default_hdr':
> >> subversion/libsvn_diff/diff_file.c:894: return value of 'svn_io_stat'
> >
> > .. because the function 'can't fail', and:
>
> By "can't fail" do you mean "the calling function doesn't return an
> error"? The svn_io_stat call can certainly fail so at the very least
> do:
>
> svn_error_clear (svn_io_stat (...));
>
> or
>
> err = svn_io_stat (...);
> if (err)
> {
> file_info.mtime = 0;
> svn_error_clear (err);
> }
>
By 'can't fail', I meant that svn_diff__file_output_unified_default_hdr()
doesn't provide any way to communicate an error to its caller, and so I
wasn't sure how best to fix the leak offhand.
Since it's static, it should be easy enough to adjust the function to
return an svn_error_t*, then we can add in an SVN_ERR() macro. I think
that's preferable to ignoring the error, no?
> >> Of course the other question raised is: do we want to consider using such
> >> attributes as a matter of course? Obviously only if it is done neatly and
> >> in a way that doesn't interfere with other compilers; macros can help to
> >> achieve that. I'll have a bit more of a think about that.
> >>
> >
> > Yes, we should do this by default, if we can. Any idea how?
>
> No problem, we already use __attribute__ in the public API.
>
So do we add a macro that expands to '__attribute__(...) svn_error_t *'
and adjust all the existing function declarations/definitions to use that?
That's the obvious solution, but I was hoping that Julian might be able
to come up with something more cunning ;-)
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 23 20:43:33 2006