[FFmpeg-devel] [PATCH] silence "may be used uninitialized" warnings

Dave Dodge dododge
Fri Sep 21 10:53:49 CEST 2007


On Fri, Sep 21, 2007 at 01:05:40AM -0400, Rich Felker wrote:
> On Fri, Sep 21, 2007 at 01:32:02AM +0200, Diego Biurrun wrote:
> > > +#ifndef uninitialized_var
> > > +#    define uninitialized_var(x) x=x
> > > +#endif
> 
> The code in this patch is not valid C afaik. Even if it is, the
> variable is still used uninitialized in the construct int x=x;

>From a quick look, the Standard is unclear on whether an identifier is
visible to its own initializer.  As you say, at that point taking its
value would be undefined anyway.  However taking its sizeof would be
valid, so it's not entirely cut and dry.

> If gcc is not reporting the warning here, it's a bug in gcc's
> warning generation. So IMO this workaround has no merit...

It's a known deficiency in gcc.  The gcc manual gives some examples of
problem situations, such as:

    int save_y;
    if (change_y) save_y = y, y = new_y;
    ...
    if (change_y) y = save_y;

gcc isn't smart enough to figure out that save_y will only ever be
used if it was also initialized.  Even if gcc _could_ handle that
case, it's easy to make it a lot harder:

    int save_y;
    if (v1) save_y = y, y = new_y;
    ...
    if (v2) y = save_y;

and then have the relationship between v1 and v2 be complex, or
expressed in a different translation unit.

gcc does not have an attribute similar to __unused__ to mark these
cases.  I have no idea why not, as it would seem to be a perfect place
for one.  Instead the usual "solution" is to self-initialize.  In fact
gcc intentionally does _not_ warn about self initialization unless you
enable -Winit-self, presumably for exactly this reason.

                                                  -Dave Dodge




More information about the ffmpeg-devel mailing list