You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2014/04/04 13:12:21 UTC

Re: r1577280 [1/3] - fsfs-lock-many

Hi Philip.

> Modified: subversion/trunk/subversion/libsvn_fs_fs/lock.c
> ==============================================================================

> +static svn_error_t *
> +unlock_single(svn_fs_t *fs,
> +              svn_lock_t *lock,
> +              apr_pool_t *pool)
> +{
> +  struct unlock_baton ub;
> +  svn_sort__item_t item;
> +  apr_array_header_t *targets = apr_array_make(pool, 1,
> +                                               sizeof(svn_sort__item_t));
> +  item.key = lock->path;
> +  item.klen = strlen(item.key);
> +  item.value = (char*)lock->token;
> +  APR_ARRAY_PUSH(targets, svn_sort__item_t) = item;
> +
> +  ub.fs = fs;
> +  ub.targets = targets;
> +  ub.skip_check = TRUE;
> +  ub.result_pool = pool;
> +
> +  SVN_ERR(unlock_body(&ub, pool));

This leaks the error that's potentially returned in UB->fs_err, doesn't it?

(And the same in the equivalent FSX function.)

> +
> +  return SVN_NO_ERROR;
> }

- Julian


Re: r1577280 [1/3] - fsfs-lock-many

Posted by Philip Martin <ph...@wandisco.com>.
Julian Foad <ju...@btopenworld.com> writes:

>> +  ub.skip_check = TRUE;
>> +  ub.result_pool = pool;
>> +
>> +  SVN_ERR(unlock_body(&ub, pool));
>
> This leaks the error that's potentially returned in UB->fs_err, doesn't it?

No, it doesn't because skip_check is TRUE. I've added 1584706 to
explain.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*