[vlc-devel] commit: signals: Return NULL at SigThread end. (Pierre d'Herbemont )

[Rémi Denis-Courmont]

Le vendredi 21 août 2009 23:08:57 Pierre d'Herbemont, vous avez écrit :
> > different
> > warnings depending on its version and optimization level. If it
> > detects that
> > this is dead code, it will complain about dead code. Then again, it
> > might -
> > wrongly- complain about lack of return value.
>
> I see your point better, however, I still consider this to be
> anecdotical or less important than the warnings sanitization.

I *refuse* to put known to be dead code into the code. This is *wrong*.

> Also, as time advance, we'll get a better platform coverage and tuning
> with --enable-treat-warnings-as-error, this way.
>
> This might seems like a dictatorial solution but I believe this will
> actually help VLC development.

I am seeing very much the opposite. Already when *I* enabled many more 
warnings, people started "working around" the warnings instead of actually 
fixing the problems. Now, it looks like it got worse. And while I could blame 
developers for handling warnings badly, I cannot quite blame them for fixing 
errors - they just want to be able to build VLC.

> I believe that if it's good to make sure that contributors and build
> bot build VLC with --enable-treat-warnings-as-error. We'll filter out
> warnings. It seems to me that this solution is the most realistic to
> force adoption. We let packagers use --disable-treat-warnings-as-error.

I still did not make sense to mandate Werror with --enable-debug, though I 
lifted that restrictions.

> I can conceive that we could do the other way around, and if there is
> too much complaint we could --enable-treat-warning-as-error on build
> bot and find a way to get contributor to build with it. Yet, I fear
> that this could mean simply ignoring deadly warnings again.

I am all for erroring out on deadly warnings. But I don't find unused 
parameters or unused variable to be deadly for instance. On the other hand, 
really bad warnings like incompatibile function pointers or type-punning 
violation are not errors...

-- 
Rémi Denis-Courmont
http://www.remlab.net/