[FFmpeg-devel] questions about warnings

John Calcote john.calcote
Fri Jul 16 22:23:55 CEST 2010


Thanks very much M?ns for the information - and the the invitation. I'd
love to help out. I'll do some investigating to see what I can find on
the ones that you found to be a potential problem. I'm pretty careful
not to change things in a way that does more harm than good...

Also, thanks for the tip on the SUSE gcc. This is the Opensuse 11.1
release of gcc from more than a year ago. I'm about to update my system
to 11.3 (just released a few days ago). Hopefully they've worked out the
kinks by now.

Regards,
John

On 7/16/2010 1:53 PM, M?ns Rullg?rd wrote:
> 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
>> --extra-cflags='-funit-at-a-time'
>>
>> $ 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:
>>
>> deprecation:
>>    * 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
>> instances)
>>     
> 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
>> instance)
>>     
> 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.
>
>   
>> suggestions:
>>    * 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.
>
>   




More information about the ffmpeg-devel mailing list