> On Jan 26, 2015, at 9:28 AM, Darin Adler <da...@apple.com> wrote:
> 
> I have found serious bugs in WebKit with unused parameter warnings; I found 
> some when first turning on the warning. I don’t have a specific story to 
> tell, but I remember there was more than one case.
> 
> So far it’s been impractical to turn on this warning for our Objective-C 
> code, since we can’t simply omit argument names, and that’s why it’s not on 
> in the Mac versions of those frameworks.
> 
> And I do agree that it can be inconvenient to deal with these warnings in 
> heavily #ifdef’d code. I think there are some good strategies for avoiding 
> that, and I’d like to talk about specific irritating cases so I can propose 
> the strategy I’d push for. Generally the strategy is to push more 
> configuration specifics to the edges rather than spreading them through 
> multiple functions.

A strategy that works well for me for reducing the total number of #ifdefs is 
to put them in the implementation of a method rather than around the whole 
method. Of course this strategy is ultimately unavoidable - if you have any 
method that is only declared on some configuration then somewhere you will have 
a conditionalized call to that method. So I actually do the opposite of pushing 
the configuration conditionals to the edges - I put them into the innards. I 
believe that this reduces both the total number of #ifdefs and the total number 
of places where unused parameter situations arise. My experience here may be 
because this is the best way to deal with things like CPU and OS; I don't know 
what it's like for feature flags. 

Either way though, you eventually have some code in some method body that will 
be conditionalized. This leads to two cases of compiler spoonfeeding:

1) unused parameters

2) unreachable code

We have a good way of dealing with (2) - UNREACHABLE_FOR_PLATFORM. This tells 
the compiler that you won't return but deactivates the noreturn attribute 
warning. That's probably as good as it gets for unreachable code - even if the 
noreturn warning wasn't enabled we would still want to make sure that 
presumed-unreachable code aborts if called. 

For unused parameters I don't know of a case where it caught a bug but I end up 
dealing with build failures - either on EWS or after commit - due to the 
warning. 

> 
> — Darin
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to