[FFmpeg-devel] How to handle compiler warnings
Tue Jan 29 15:40:18 CET 2008
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
hmm i dont remember but i do remember diego breaking nut.c with a
() warning fix :)
Anyway it was fixed quickly IIRC ...
I think the point to learn here is that warnings should be treated as
potential bugs and be fixed with the neccessary care.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I wish the Xiph folks would stop pretending they've got something they
do not. Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel