[FFmpeg-devel] How to handle compiler warnings

Michael Niedermayer michaelni
Wed Jan 30 06:40:20 CET 2008

On Tue, Jan 29, 2008 at 12:03:15PM +0100, Michel Bardiaux wrote:
> 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.
> > 
> IMNSHO all warnings should be fixed and warning-is-error turned on. In 
> my experience (not on ffmpeg code), that leads to 99% of trivial 
> warnings being fixed trivially, 1% being danger sign and fixed 
> trivially, and I have never found one that could only be fixed using bloat.

see libavutil/aes.c its just a little over 200 lines and causes a page of
warnings to be printed.
Its easy to fix but one has to obfuscate the code with casts. If someone
has a better idea iam all ears ...

That is besides the obvious, "patch gcc so it doesnt consider [4][4]!=[16]
and similar near identical things"

Also adding a "this causes a harmless warning" all over the place like
someone suggested doesnt seem that good for aes.c. There are too many warnings,
sometimes even 3 from a single line.

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080130/490bd77a/attachment.pgp>

More information about the ffmpeg-devel mailing list