[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: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-01-24 21:43:05 CET

On 1/24/06, Julian Foad <julianfoad@btopenworld.com> wrote:

> I decided to include the return type in the macro, mainly for brevity at the
> point of use, but justified by the idea that the return type and the
> instruction not to ignore it are closely associated with each other. For
> example, the equivalent instruction to a different compiler might well require
> being placed before or after or around the return type:
> __no_ignore(svn_error_t *) f(...);
> svn_error_t * _Pragma(no_ignore) f(...);
> Of course some compiler might require such an instruction to come after the
> function name, which this wouldn't support. I do NOT believe it is very
> important to try to make other compilers do this same checking. The more
> checks the better, but some compilers will always check things that others
> don't, and that's fine.
> How do people feel about me committing this? The patch I have ready covers all
> (1200 or so) declarations in header files. I suppose I should do the same for
> all the (1700 or so) "static" functions too - leaks from them are no less
> important.

Honestly, I'm not a huge fan of the macro including the svn_error_t *,
it makes the headers harder to read. If we must have such a thing,
I'd prefer something like SVN_DECLARE(svn_error_t *) or something,
similar to the way that the APR_DECLARE stuff is done,s ince at least
you can still see the return value. On the other hand, I belive
Branko was against the presence of such a macro when one was suggested
to deal with the windows DLL build issues, so that might have its own


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 24 21:43:40 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.