Re: Uninitialized "out" parameters

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

In article <4t20tb$1bum@info4.rus.uni-stuttgart.de>,
Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de> wrote:
>For the Ada83 class of errors I ask you for an example.

I gave such an example in a previous post.  You have to build up the
result in a local variable, and the possible bug is that you forget to
assign the local into the 'out' parameter.  This is at least as likely
as the potential bug prevented in Ada 83, which is where you read the
'out' param before initializing it.

>I consider the current Ada95 rule a true source of errors
>and therefore a nasty property of the language.

As explained above, the Ada 83 rule is *also* a true source of errors.
The only real solution is to have a comprehensive rule for detecting
uninitialized vars, either at run time or compile time (or both).

>I could imagine an Ada2005 where the compiler is obliged to only
>allow any downstream reading of mode-"OUT"-parameters 
>when the context clearly indicates a prior setting,
>whatever flow of control was taken before.

The problem isn't OUT params in particular.  The problem is uninit vars.
If Ada 05 is to solve the problem, it ought to do so in a uniform manner
for all variables, not just OUT parameters.

>BTW, under NO circumstances I would accept an incoming value of 
>a formal OUT parameter as data to be processed. I am sure you all agree.

Well, I'll bet you accept incoming discriminants and array bounds.
Other than those, I agree.

>I am not satisfied with the language concerning
>the handling of non-initialized variables in general.

Agreed.

>This has been discussed long time ago. 
>I remember e.g. the efficiency aspect.

And agreed.

- Bob