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

Re: Safe to add a field to svn_error_t?

From: Blair Zajac <blair_at_orcaware.com>
Date: Fri, 24 Dec 2010 10:32:35 -0800

On 12/24/10 6:07 AM, Hyrum K Wright wrote:
> On Fri, Dec 24, 2010 at 12:10 AM, Blair Zajac<blair_at_orcaware.com> wrote:
>> The addition of "tracing" to svn_error_t in 1.7 currently uses a special
>> message string "traced call". Instead of doing this, can we safely add an
>> svn_boolean_t to svn_error_t the indicates if it is a traced error?
>>
>> While svn_error_t is public, I'm hoping most people are creating them with
>> svn_error_create*(), so if that's the case, then code written and compiled
>> against svn<= 1.6 would work fine when linked against a 1.7 library.
>>
>> Thoughts?
>
> We don't explicitly say "only use approved methods to create this
> object", but we are pretty implicit about it, with an entire
> documentation group for "Error creation and destruction". I'm on the
> fence on this, but would lean toward "go ahead and extend the struct"
> if pressured.
>
> What problem are you trying to solve?

There's this comment in svn_error__is_tracing_link():

svn_boolean_t
svn_error__is_tracing_link(svn_error_t *err)
{
#ifdef SVN_ERR__TRACING
   /* ### A strcmp()? Really? I think it's the best we can do unless
      ### we add a boolean field to svn_error_t that's set only for
      ### these "placeholder error chain" items. Not such a bad idea,
      ### really... */
   return (err && err->message && !strcmp(err->message, SVN_ERR__TRACED));
#else
   return FALSE;
#endif
}

I thought of two other solutions:

1) a sentinel message and we compare by address.
2) negative source file line numbers.

Blair
Received on 2010-12-24 19:33:20 CET

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