[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: More error leaks

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2006-01-23 20:43:04 CET

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 ;-)


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.