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

Re: svn commit: r22765 - trunk/subversion/libsvn_client

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: 2006-12-20 16:03:01 CET

Daniel Rall wrote:
> On Wed, 20 Dec 2006, Kamesh Jayachandran wrote:
>
>
>> dlr@tigris.org wrote:
>>
>>> Modified:
>>> trunk/subversion/libsvn_client/copy.c
>>>
>>> Modified: trunk/subversion/libsvn_client/copy.c
>>> URL:
>>> http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_client/copy.c?pathrev=22765&r1=22764&r2=22765
>>> ==============================================================================
>>> --- trunk/subversion/libsvn_client/copy.c (original)
>>> +++ trunk/subversion/libsvn_client/copy.c Wed Dec 20 06:06:12 2006
>>>
>>> /* Check that all of our SRCs exist, and all the DSTs don't. */
>>> for (i = 0; i < copy_pairs->nelts; i++)
>>> @@ -221,7 +220,7 @@
>>> ((svn_client__copy_pair_t **) (copy_pairs->elts))[i];
>>> svn_node_kind_t dst_kind, dst_parent_kind;
>>>
>>> - svn_pool_clear(subpool);
>>> + svn_pool_clear(iterpool);
>>>
>>> /* Verify that SRC_PATH exists. */
>>> SVN_ERR(svn_io_check_path(pair->src, &pair->src_kind, pool));
>>>
>> Why not this svn_io_check_path from iterpool?
>>
>
> As I mentioned in a separate email, this operation allocates memory
> for our input parameters. I want to avoid altering their values, then
> destroying the memory holding their new values. While I don't believe
> that those values are used now, this is a safe practice which leaves
> the code without booby-traps (and thus easier to modify).
>
> - Dan
>
Given the call it can only modify '&pair->src_kind' as 'pair->src_kind'
is an enum it does not need any allocation, so no need to worry abt pool
destruction.

With regards
Kamesh Jayachandran

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 20 16:03:31 2006

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