[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: Sat, 25 Dec 2010 14:48:09 -0800

On 12/24/10 10:32 AM, Blair Zajac wrote:
> 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)
> {
> /* ### 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.

Realized later that this won't work because svn_error_dup() will copy the
message and constructing a new error also copies the message, so the comparing
addresses won't work.

Received on 2010-12-25 23:48:52 CET

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.