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

Re: [PATCH] Move unused parameter warning suppression into a macro

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-10-26 12:51:37 CEST

Jonathan Gilbert wrote:
> At 12:21 PM 25/10/2005 +0100, Julian Foad wrote:
>>If you mean all the "unused parameter" warnings, then yes; I hope Jonathan will
>>do that.
> If you commit the basic patch, then I'll do that. Otherwise, I'll be stuck
> with trying to split it into two diffs against HEAD, which I don't feel
> comfortable doing... Unless there's a better way :-)

In this case, it's not worth splitting the patch into "implement the macro" and
"use the macro" because both parts are so simple (even though the latter part
is large), so just put it all in a single patch.

If you did want to make two separate diffs against HEAD, it's easy to do so
because the changes are in separate files:

   svn diff subversion/include/types.h > unused-param-implement.patch
   svn diff subversion/{lib*,clients,svn*}/ > unused-param-use.patch

By the way, the log message for this last part of the change doesn't (in my
opinion) need to have too much detail. Perhaps list the files in which the
macro is used, but not the names of the functions.

I'm still thinking about whether we can do better than putting the definition
in svn_types.h. We really should try hard to avoid using that file as a
dumping ground. I'm thinking svn_private_config.h would be better, since this
is an implementation detail that users of our libraries don't need to know
about, and since the appropriate definition might depend on the compilation
environment. For example, some compilers might complain more about "(void)x"
being a statement with no effect than they do about unused parameters.

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 26 12:53:15 2005

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.