[vlc-devel] commit: signals: Return NULL at SigThread end. (Pierre d'Herbemont )
remi at remlab.net
Sat Aug 22 08:52:26 CEST 2009
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...
More information about the vlc-devel