On Mon, Jan 14, 2013 at 10:33 PM, Lucas De Marchi <
lucas.demar...@profusion.mobi> wrote:
> On Mon, Jan 14, 2013 at 6:32 PM, Tom Hacohen <t...@stosb.com> wrote:
> > How is this a bug in the compiler?
> > bla = func_name;
> > and
> > bla = var_name;
> > are both valid C statements, it's a bug if they "fixed" it.
>
> both are valid, not together... what are you trying to do here?
>
> I am not saying -Wshadow is useless. In the snippet below the warning
> is valid (and GCC 4.7 correctly warns about it):
>
> int f(void)
> {
> return 0;
> }
>
> int main(void)
> {
> int f = 0;
> return f++;
> }
>
> However in the following snippet there's no way the programmer would
> be confused about signal:
>
> #include <signal.h>
>
> int main(void)
> {
> int signal = 0;
>
> return signal;
> }
>
>
> signal is a pointer to a function that lives in another TU. What I am
> saying is essentially the same Linus said on his email I pointed out.
>
I know this thread, I've read it before. I disagree with that statement
though.
int main(void)
{
void *signal = NULL;
void *signal2 = signal;
...
return signal2 == NULL;
}
Once you remove the shadowing variable declaration you'll be left with
broken code. That's why shadow exists and it makes no difference if it's a
local int or a global function. We use void * in our code, it's not that
uncommon that we'll get this.
Furthermore, our code compiles just fine with -Wall -Wextra -Wshadow, so
why not maintain it if it's so easy? This may be annoying for the kernel or
systemd that have a lot of shadowing, but we can get the benefits of
-Wshadow with the "annoyances" that Linus describes.
>
> >
> > Furthermore, as mike said, it does no harm, and having a warning free
> > compilation is very important.
>
> sure. and I agreed with the exception of useless warnings. For
> example, here with gcc 4.7 I didn't have the problem he "fixed".
>
Yeah, but we want all the compilations to compile without warnings so
buildbot reports will be meaningful, and that people will be able to
compile and check for themselves that there were no added warnings in their
changes, even if they use "old" compiler versions.
>
>
> >
> > unused-parameter is a very useful warning, I wouldn't ignore it if I were
> > you.
>
> What am I missing? Do you have an example in real world that turning
> this warning on discovered a bug? I never saw one. And this was
> after turning it on on projects that previously didn't have it.
>
It shows you when your function actually accepts parameters it doesn't
need (i.e they should be removed), or if you forgot to take them into
account in the function code and should use them. This is very useful when
you split your code into smaller functions that you change and you would
like to easily know if your new algorithm doesn't take a parameter into
account or not. This can be achieved in other ways as well, but the good
thing about warnings is that they force themselves on you, whether you ask
for them or not. :)
>
>
> >
> > The only place unused parameter is uselessly annoying is callbacks.
>
>
> oh... there you got it... our libs are all about callbacks and that's
> why I hate -Wunused-parameter. I hate "fixing" warnings by simply
> shutting up the compiler with var attributes. A warning is relevant
> only when it points to real problems.
>
Can't argue with that. :)
--
Tom.
------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
