Re: Uninitialized "out" parameters

[adam@irvine.com (Adam Beneschan)]

"James A. Squire" <m193884@CSEHP3.MDC.COM> writes:
 >Adam Beneschan wrote:
 >>
 >> This rule change frightens me a little.  In the posted example:
 >>
 >>    procedure SubP (op : out integer) is
 >>    begin
 >>       op := op + 1;
 >>    end SubP;
 >>
 >> I've been known to accidentally type "out" when I mean "in out".  In
 >> Ada 83, the compiler would catch me, but now it won't, and the effect
 >> will be very different because here the "op" on the right side of the
 >> assignment is always uninitialized.  However, I guess a smart compiler
 >> would let me know that I'm using an uninitialized parameter, and
 >> perhaps the advantages of letting you read an OUT parameter after
 >> you've written to it outweigh this disadvantage.
 >
 >I tried to find out from the LRM if this compiler behavior is required,
 >but I don't see it anywher in chapter 6.  
 
I'm not sure what you're referring to by "this" compiler
behavior--whether you mean that it treats "op" as uninitialized, or
whether you're referring to giving a warning about using an
uninitialized parameter.  The first is covered by 6.4.1(12-15):

"For an out parameter that is passed by copy, the format parameter
object is created, and:  . . ."

"For any other type [besides access types and certain composite
types], the formal parameter is uninitialized. . . ."

 >I do know that in 6.1.1 of the
 >Ada95 Rationale, it has the following paragraph:
 >
 >"For Ada 95, we have removed the restrictions on the use of out
 >parameters.  Specifying that a formal parameter is of mode out indicates
 >that the caller need not initialize it prior to the call. However,
 >within the procedure, once the
 >                                                                    ^^^^^^^^
 >parameter has been initialized, it may be read and updated like any
 >other
 >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 >variable. As with a normal variable, it is an error to depend on the
 >value of an out parameter prior to its being initialized."
 >
 >but I don't know if that's a compiler error or a run-time error.  From
 >the context, I'd guess a run-time error.

I'd guess it's the same as for any uninitialized object, which is a
bounded error that most likely won't be caught.

                                -- Adam