[FFmpeg-devel] How to handle compiler warnings

Diego Biurrun diego
Wed Jan 30 09:04:29 CET 2008


On Wed, Jan 30, 2008 at 06:40:20AM +0100, Michael Niedermayer wrote:
> 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.

You can always add a comment at the top of the file saying that the x
number of warnings that get printed are harmless.

Diego




More information about the ffmpeg-devel mailing list