[FFmpeg-devel] questions about warnings
Fri Jul 16 21:53:01 CEST 2010
John Calcote <john.calcote at gmail.com> writes:
> Hi list,
> I'm building ffmpeg (svn revision 24250) using the following configuration:
> $ ../svn/configure --enable-postproc --enable-gpl --enable-x11grab
> --enable-pthreads --enable-nonfree --enable-libxvid --enable-libmp3lame
> --enable-libvorbis --enable-runtime-cpudetect --enable-libfaac
> $ gcc --version
> gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]
Be warned, suse gcc has been known to miscompile ffmpeg. I don't
remember which version it was.
> I'm finding a lot of warnings. (Please don't take this wrong; I'm not
> accusing anyone - other than myself - of not managing warnings
> properly.) Here's my itemized and categorized list:
> * XXX is deprecated [deprecation attribute - nice compiler feature]
> (10 instances)
> * #warning header deprecated (2 instances)
Mostly AVPaletteControl IIRC. These are from obscure formats nobody
seems to care about. Nevertheless, they should be fixed.
> uninitialized usages:
> * XXX may be used uninitialized (40 instances)
Most of these are known to be false positives. The high false
positive ratio makes it rather annoying to look for the genuine ones.
If you want to help with this, that would be very welcome.
> array subscript:
> * array subscript is below array bounds (1 instance)
I remember seeing that. IMO it should be fixed.
> pointer target type:
> * assignment discards qualifiers from pointer target type (17 instances)
Most of those are in the bitstream filters. The API makes these
warnings impossible to avoid there.
> * passing argument X discards qualifiers from pointer target type (8
These should be investigated. Adding a const to the parameter
declaration should hopefully be enough.
> * return discards qualifiers from pointer target type (2 instances)
These are avstring functions IIRC. Impossible to avoid.
> * initialization discards qualifiers from pointer target type (1
I don't remember this one. Please quote it in full.
> incompatible assignments:
> * assignment from incompatible pointer type (4 instances)
> * initialization from incompatible pointer type (18 instances)
> * passing argument X from incompatible pointer type (27 instances)
Most of these are multi-level pointers having const added. Usually
impossible to fix.
> cast issues:
> * argument makes int from pointer without cast (1 instance)
Please quote. This is either a real bug or easily fixed.
> * cast from pointer to int of different size (12 instances)
These can probably be fixed by using intptr_t instead of int. There
was some discussion about this a while ago. "Discussion" means lots
of people had an opinion but nobody did anything.
> * cast discards qualifiers from pointer target type (21 instances)
Please check if adding a const to the cast fixes these. It could be
that this simply pushes the warning along.
> command-line option or attribute override:
> * force_align_arg_pointer attribute ignored (8 instances)
There was a patch posted to enable this only on x86. On second
thoughts, we should probably apply that patch. No other architectures
rely on stack alignment beyond ABI requirements.
> * suggest parentheses around comparison (9 instances)
These are annoying as hell. The parenthesised code is often
nigh-impossible to read compared to the bare version.
> For the amount of source code in question, this isn't really that bad. I
> just want to make sure I'm not supposed to supply additional config or
> make options to remove a chunk of these.
> The ones I worry about the most are the array subscript, pointer target
> type, incompatible assignments, and cast issues. These are generally the
> problem areas when porting - especially from 32- to 64-bit platforms.
FFmpeg is tested on a huge number of platforms. There should be no
such portability issues in the code.
> I'm also worried about the fact that I had to supply the
> --extra-cflags='-funit-at-a-time' option to remove 80 percent of the
> warnings I encountered on my first build attempt.
That sounds wrong. That flag is enabled by any optimisation level so
should make no difference when given explicitly.
mans at mansr.com
More information about the ffmpeg-devel