Michael Sinz wrote:
> Julian Foad wrote:
>
>> Jonathan Gilbert wrote:
>>
>>> Move unused parameter warning suppression into a macro instead of directly
>>> using "(void)p;" or "p=p;" in otherwise semantically-oriented source code.
>>
>> Are you planning to follow up with a patch that inserts this macro
>> into the dozens (from memory) of other places where we intentionally
>> ignore a parameter, so as to make the whole build "clean"? If so, +1;
>> if not, I don't think there is any point in having this and we should
>> just delete those three instances of ad-hoc warning-suppression that
>> you found.
>
> I believe that this is a good patch. Yes, it will be nice to fix all
> of the warnings, but even if it does not do so in one patch does not
> mean that it is a bad idea or a step in the wrong direction.
To be useful, it has to be used. To use it, we have to define this macro, we
have to turn on the "unused parameter" warnings in our builds, and we have to
insert this macro in every place where a parameter is unused. What I am saying
is that there is no benefit in doing part of this if we are not intending to do
all of it.
> (Personally, my own code always must compile clean - no warnings - before
> I release - so any steps to that condition are good, IMHO)
I like a "clean" compile too, but there is no canonical definition of "clean".
We choose our own level of "cleanliness" by enabling and disabling certain
warnings. I don't normally see any "unused parameter" warnings because I
disable them because I know that we don't currently attempt to avoid them.
> PS - if someone were to get all warnings out in a single patch, would that
> be something to look at? I assume we are mainly worried about GCC.
If you mean all the "unused parameter" warnings, then yes; I hope Jonathan will
do that.
If you mean more than that, then you have to choose and specify what warnings
you mean.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 25 13:23:45 2005