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