[FFmpeg-devel] [PATCH] [RFC] fix 'may be used uninitialized' warnings

[Måns Rullgård]

Diego Biurrun <diego at biurrun.de> writes:

> On Mon, Feb 02, 2009 at 10:41:46PM +0100, Michael Niedermayer wrote:
>> On Mon, Feb 02, 2009 at 10:15:44PM +0100, Diego Biurrun wrote:
>> > On Mon, Feb 02, 2009 at 04:02:42PM +0100, Michael Niedermayer wrote:
>> > > On Mon, Feb 02, 2009 at 12:59:19PM +0100, Diego Biurrun wrote:
>> > > > On Mon, Feb 02, 2009 at 12:49:43PM +0100, Michael Niedermayer wrote:
>> > > > > On Mon, Feb 02, 2009 at 11:43:16AM +0100, Diego Biurrun wrote:
>> > > > > > Here is a patch to fix all but one 'may be used initialized' warning
>> > > > > > in FFmpeg.  Regression tests pass, so this cannot have broken things
>> > > > > > too badly, but some of it may nonetheless be suspicious.
>> > > > > > 
>> > > > > > Please review, I will commit individual hunks as they get approved,
>> > > > > > not before.
>> > > > > > 
>> > > > > > --- libavcodec/eatgv.c	(revision 16938)
>> > > > > > +++ libavcodec/eatgv.c	(working copy)
>> > > > > > @@ -63,7 +63,7 @@
>> > > > > >      unsigned char *dst_end = dst + width*height;
>> > > > > > -    int size,size1,size2,offset,run;
>> > > > > > +    int size, size1, size2, offset = 0, run;
>> > > > > >      unsigned char *dst_start = dst;
>> > > > > >  
>> > > > > >      if (src[0] & 0x01)
>> > > > > 
>> > > > > very obviously false positive, it can never be read without prior init
>> > > > 
>> > > > What about all those falso positives?  Are those hunks OK to commit?
>> > > 
>> > > no
>> > > IMHO if a warning is wrong it should be fixed without changing the generated
>> > > code. Of course there may be desireable changes in the code that might
>> > > remove a warning as a sideeffect but adding =0 is not.
>> > > If theres a =0 then the reader thinks it IS used which can in principle
>> > > lead to confusion.
>> > 
>> > How about adding comments like
>> > 
>> > // silence gcc
>> > 
>> > to those cases?  
>> 
>> thats better than not having such comment
>> 
>> > We have similar warning workarounds in a lot of places
>> > already...
>> 
>> sadly ...
>
> I still think it's better to have a =0 followed by a comment in there
> than ignore the warning.  This will avoid people wasting time wondering
> about them and/or trying to fix them.  It will also silence the warning,
> making important warnings more noticeable.

The assignment will generate real code which might impact speed.

-- 
M?ns Rullg?rd
mans at mansr.com