Re: Uninitialized out parameters.

["Randy Brukardt" <randy@rrsoftware.com>]

"G.B." <bauhaus@futureapps.invalid> wrote in message 
news:ne2ngo$uea$1@dont-email.me...
> On 06.04.16 10:19, ahlan@marriott.org wrote:
...
>> But even that is not the point I'm trying to make.
>> I am suggesting that it ought not to be possible to define a null 
>> procedure
>> that has out parameters without some form of warning being issued.
>
> I think the usual answer is that the compiler is not a mind
> reader and the best you could get is a warning. Who knows?
> Maybe the technical requirements are such that the programmer
> uses a procedure like Test as a placeholder, maybe its existence
> is dictated by an abstract type, maybe a null procedure really
> should do nothing at all, which includes not touching V.

I agree with Georg here. It *seems* like checks like the one Ahlan is 
suggesting are a good idea, until you trip over one. (The check in Ada that 
every function have at least one return is a similar idea, which causes no 
end of trouble.)

I can think of at least three reasons why one might write a null procedure 
with an out parameter:
(1) The null procedure body is a TBD placeholder. It will be replaced with a 
real body at some future point, but we still want to compile.
(2) The out parameter isn't used for some implementations. This often comes 
up when there are multiple parameters. (We ran into this commonly in Claw, 
although we usually used in out parameters in such cases to avoid 
de-initializing objects.) The situation is that some objects need additional 
return information and others don't:
     procedure Do_Something (Obj : in out Object; Result : in out 
Result_Type; Extra_Info : out Natural);
Extra_Info is only used if Result has a particular value.
(3) The null procedure is used in an interface. In that case, giving a body 
isn't possible.

I think you could make a case that all of these are better written some 
other way, but that's irrelevant, in that each of these could happen in real 
code, and making a legality check would break that code. (Thus, making it 
illegal would probably be considered too incompatible for future Ada, unless 
of course we discovered some semantic problem that doing that would fix.)

The Ada Standard has nothing to say about warnings (other than for pragmas). 
Perhaps some future version of Ada will change that, but as of now, every 
warning is implementation-defined, and thus it they don't have anything to 
do with the language. (That is, talk to your vendor about warnings.)

                                      Randy.