Re: Finding out parameters which are not written

[bobduff@world.std.com (Robert A Duff)]

In article <33F07EA1.51D1@aut.alcatel.at>,
Gerhard Radatz  <gerhard.radatz@aut.alcatel.at> wrote:
>Gerhard Radatz wrote:
>> 
>> Does anyone know about a tool which can detect such situations as the
>> following:
>> 
>>         procedure xxx (result: out INTEGER) is
>>         begin
>>              if <<condition>> then
>>                  result := 0;
>>              end if;
>>         end;
>> 
>> Obviously, this proc is erroneous and result will not be written if
>> <<condition>> is FALSE.

>I admit that it is very difficult to find such potential problems at
>compile time. ...

It doesn't seem so hard to me.  The compiler can just check whether
every path through the function assigns to every 'out' parameter of a
scalar type.  If not, warn -- it's almost certainly a bug.  (For
composite types, it's not formally erroneous, and not necessarily a
bug.)  There's no practical reason to worry about the fact that
<<condition>> might be always True (which of course the compiler can't
know, in general).

GNAT does exactly this sort of analysis for function returns -- it makes
sure that every path through the function ends with a return statement,
or the raise of an exception (and it has some mechanism for marking
procedures that always raise an exception).  I don't know if GNAT does
something similar for scalar 'out' parameters, but it could.

Of course, none of this solves the more general problem of uninitialized
objects -- that really requires run-time checks.

- Bob