Re: Dubious "'foo' might be used uninitialized in this function" message

[Robert Dewar <dewar@adacore.com>]

Dmitry Antipov wrote:

>> it gets as complex as the halting problem :)
> Really ? Why ?

Because the general evaluation of compile time contants
is clearly in this territory. Your example:

     1  #include <unistd.h>
     2
     3  int f (int x, int y)
     4  {
     5   int z;
     6
     7   if (x)
     8     z = getppid ();
     9   y = getpid ();
    10   if (x)
    11     y += z;
    12   return x + y;
    13  }

requires the compiler to do symbolic evaluation of the
tests in lines 7 and 10 and determine that they always
have the same truth value. Then you expect the compiler
to do an analysis of the flow of the program for the two
cases, and determine that everything is OK in both cases.

Yes, it is conceivable, though really *quite* difficult
to do this in a simple case like this, but obviously
impractical/impossible in more complex cases.

The compiler is complaining about line 11, because as far
as it is concerned, z has not been unconditionally assigned
previously. It is simply not in the business of saying "ah,
but it's OK, we would never have got to line 11 unless the
condition in line 10 was true, in which case the condition
in line 7 would have been true, which means that z would
have been assigned at line 8".

Warnings are warnings, not errors. Usually they are warnings
precisely because it is impossible to precisely separate the
bad cases from the good cases. The art of warning design is
to give as many useful warnings as possible without giving
too many false positives, and without requiring any extensive
analysis that the compiler is not doing anyway.

Here is an example from Ada:

      1.        generic
      2.           type R is private;
                        |
         >>> warning: type "R" is not referenced

      3.        package Q is
      4.           X : Integer;
      5.        end Q;

One of our customers recently complained that this was a false
positive, because there might be a child unit of Q that references
R. This is true. However, after quite a bit of dicussion, we
decided that it was useful to retain the warning, since it is
rather unusual (though certainly legal) to have entities that
are referenced ONLY in a child unit, and if we removed the
warning on this basis, we would lose a lot of useful warnings.
child unit