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

Re: [RFC] Replacement for "assert" in the libraries

From: Martin Furter <mf_at_rola.ch>
Date: Wed, 18 Jun 2008 17:37:09 +0200 (CEST)

On Tue, 17 Jun 2008, David Glasser wrote:

> On Tue, Jun 17, 2008 at 2:49 PM, Martin Furter <mf_at_rola.ch> wrote:
>>
>>
>> On Tue, 17 Jun 2008, David Glasser wrote:
>>
>>> On Fri, Jun 13, 2008 at 11:00 AM, David Glasser
>>> <glasser_at_davidglasser.net> wrote:
>>>>
>>>> Additionally, assert/abort generally gives good stack traces
>>>> when run in gdb, whereas it's trickier to track down the source of our
>>>> error objects.
>>>
>>> Hmm, nobody's really responded to this point of mine. Am I seriously
>>> the only person who appreciates how assert/abort works better with gdb
>>> than our errors?
>>>
>>> Or to the point: does everybody else have some special trick for
>>> getting the breakpoint at the right place with svn_error_t in gdb that
>>> I don't know about?
>>
>> I believe Julian mentioned that you can have both:
>>
>> #ifdef MAINTAINER_MODE
>> #define SVN_ASSERT(x) assert(x)
>> #else
>> #define SVN_ASSERT(x) if(x) return svn_error_create(...)
>> #endif
>>
>> Wouln't that be enough?
>
> So when I'm building in maintainer mode (ie, all my active dev), I can
> happily write void functions with SVN_ASSERT in them, which fail to
> compile without maintainer mode? No thanks.

OK, maybe the fix is using a new function:

svn_error_t*
svn_error_create_or_abort(...)
{
#ifdef MAINTAINER_MODE
   abort();
#endif
   return svn_error_create(...);
}

and always define this:
#define SVN_ASSERT(x) if(x) return svn_error_create_or_abort(...)

That should work, right?

Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-18 17:37:24 CEST

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.