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

Re: [PATCH] libsvn-fs-util: Convert error related functionsasmacros

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: 2007-06-08 09:22:00 CEST


> To be clear, so, do you suggest to change the macro definition from:
> #define SVN_FS__ERR_NOT_FILE(f, p)
> to (or something similar):
> #define SVN_FS__ERR_NOT_FILE(fs, path_inside_repo)
> in all instances (Total: 7 macros) where we may face compile error? If
> so, the naming for same parameter may vary between macros. If yes, do
> you suggest me to remove the comment which explains the type of
> parameters passed to each macro? The reason being, if we change the
> parameter to be something meaningful and with longer name, then I think,
> we need not explain the type of each argument. Hence, we can retain the
> original comment which existed against the initial function definition.
> Please let me know your comment.
We should retain the comments about type of parameters at least the
structures like 'fs' 'lock' as we dereference them.
In our code we have precedents for both 'no comment for
param'(SVN_ERR_IS_UNLOCK_ERROR in svn_error.h) and 'comments for
param'(APR_ARRAY_IDX in svn_types.h).

> So now, I think, this change is dependent on how we go about naming the
> parameter for each macro. If we are going to use a long parameter (as
> per your suggestion), then I think, we can remove the type specification
> all together from the comment. What do you think?
As mentioned above let us have type specification of 'struct' types only
in macros.


Will tweak the patch with the above comments and commit later
today(based on the availablity of net connection at home).

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 Fri Jun 8 09:21:44 2007

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.