[FFmpeg-devel] How to handle compiler warnings

[Måns Rullgård]

Michael Niedermayer wrote:
> On Tue, Jan 29, 2008 at 01:27:26PM +0200, Ivan Kalvachev wrote:
>> On Jan 29, 2008 1:02 PM, Baptiste Coudurier
>> <baptiste.coudurier at smartjog.com> wrote:
>> > Hi,
>> >
>> > Diego Biurrun wrote:
>> > > The topic has come up again, it's time to discuss the subject.  I
>> > > propose to try to avoid compiler warnings as much as possible in order
>> > > to
>> > >
>> > > - have cleaner code,
>> > > - have important warnings not be drowned out,
>> > > - make FFmpeg a programming textbook.
>> > >
>> > > This does not include warning fixes that slow things down or obfuscate
>> > > the code, but if in doubt I personally would err on the side of fixing
>> > > the warning.
>> > >
>> >
>> > I wholeheartedly support this and I agree that it must not slow down the
>> > code.
>> >
>> > If this reaches an agreement:
>> > How should we proceed ? People jumping in and fixing them at sight, or
>> > maintainers taking care of their files ?
>>
>> In MPlayer we already had incident. Diego fixed a warning in one way.
>> Then he finds out that the fix gives different result than the old
>> code and fixes it in another way. Then he gets flamed because the
>> warning indicated actual bug and he had (re)committed buggy code, in a
>> way that hides the warning. The whole issue was about trivial
>> parenthesis.
>
> hmm i dont remember but i do remember diego breaking nut.c with a
> () warning fix :)
> Anyway it was fixed quickly IIRC ...

That case was made worse by the misleading use of whitespace around
the operators.

> I think the point to learn here is that warnings should be treated as
> potential bugs and be fixed with the neccessary care.

Definitely.  That's why they're called warnings.

-- 
M?ns Rullg?rd
mans at mansr.com