[FFmpeg-devel] [PATCH V3 3/5] libavformat/protocols.c: fix build warning for [-Wdiscarded-qualifiers]

[Reimar Döffinger]

> On 27 Feb 2021, at 09:14, Guo, Yejun <yejun.guo at intel.com> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Paul B
>> Mahol
>> Sent: 2021年2月26日 19:37
>> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
>> Cc: Guo, Yejun <yejun.guo at intel.com>
>> Subject: Re: [FFmpeg-devel] [PATCH V3 3/5] libavformat/protocols.c: fix build
>> warning for [-Wdiscarded-qualifiers]
>> 
>> look at same/similar patches like yours that have been already rejected.
> 
> thanks for the info.
> 
> My motivation to fix the build warnings is that: I have several patches caught
> by patchwork with build warnings that I missed. I'd like to avoid it. And the best method,
> IMO, is to add '-Wall -Werror' for the build option.

I think that is a bad idea, compilers add new warnings all the time, many of them
unreliable or of questionable quality/usefulness.
What you end up with using -Werror is a project that constantly fails to build and gets
a reputation for low quality.
However there may well be specific, reliable warning types for which we
should add an error specifically, as we already do now for e.g.
-Werror=implicit-function-declaration
There might also be other options to improve things and ensure relevant
warnings are visible and addressed, but I’ve yet to
see a -Werror have convincing effects (for example one effect it usually
has is that people have to stick to “supported” compiler versions to avoid
constant issues with build failures, reducing testing and actually decreasing
code quality instead of increasing it).
Turning it around, using -Werror successfully would mean testing with all
compiler versions regularly including pre-release versions and ensuring
any issues are fixed immediately. Which I don’t think is an approach
that would work for FFmpeg.

> Such option can also help to find
> potential issues in the code. This is the reason that I plan to fix the build warnings
> one by one together with community.

I believe many are likely to be fixable in a way that most developers
would be quite happy with, even consider it an improvement beyond
just the warning/bug fix.
It’ll just take a lot more effort to find those types of fixes.
After all if it was that simple there could just be an option for
the compiler to fix them itself, the reason there isn’t is because
it would likely end very badly.

Best regards,
Reimar