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

[Rémi Denis-Courmont]

Le vendredi 21 août 2009 11:40:16 Pierre d'Herbemont, vous avez écrit :
> >> The above solution is the most portable one, I think.
> >
> > No. Some compilers generate warning on dead code, and some compilers
> > generate
> > warnings in both cases. There are no warning-free "portable"
> > solutions. The
> > only portable solution is to not turn warnings into errors. In fact,
> > turning
> > warnings into errors is not portable. Suck it up.
>
> Yes. That's why we are only turning on to error specific class of
> warnings, not all warnings :-)

You're missing the point. Occurences of warnings depend on the compiler, 
compiler version, architecture, targetted run-time, optimization level (at 
least). There is no portable definition of avoidable warnings. For instance, 
if you enable errors on unused results, OS X will probably build fine, but 
Linux _will_ fail. If you enable errors on incompatible pointer types, Windows 
_will_ fail but probably not Linux. If you enable alignment upcasting errors, 
ARM will fail, but x86 will do fine.

This particular case is a good example. GCC itself will generate 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.

> > This is a stupid idea, even in debug mode. If you want to enable for
> > yourself,
> > it's your problem. On ARM Linux, I have unfixable warnings due to
> > alignment vs
> > cast problems. With threads cancellation, I also get dummy clobber
> > warnings:
> > the only solution would be to use "volatile" which is just worse
> > than getting
> > a warning, IMHO. We also have warnings due to unused results from
> > glibc, in
> > some cases where we actually know what we are doing.
>
> That's why we don't enable warning on error for such warnings.

And how do you know that it's fine to enable them in ANY case?? Only those 
warnings that are *always* avoidable and very likely actual errors are 
acceptable. Sorry but unused parameters or unused variables simply do *not* 
fit that definition. Indeed, hardly any of the recent "warnings fix" addressed 
any actual *run-time* bug.

> Totally unrelated, given VLC usage of fork and setjmp, is it safe to
> assume that we'll only get false positive with -Wclobber?

Unfortunately, CPU detection uses setjmp() in a clobber-prone manner, so there 
is actual value in clobber warnings.

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