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*