From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
X-Google-Thread: 103376,8fd9e333acefd8a3
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.129.169 with SMTP id nx9mr11181727pbb.2.1334076734093;
        Tue, 10 Apr 2012 09:52:14 -0700 (PDT)
Path: 
 r9ni40887pbh.0!nntp.google.com!news1.google.com!goblin1!goblin.stu.neva.ru!feeds.phibee-telecom.net!zen.net.uk!dedekind.zen.co.uk!reader02.nrc01.news.zen.net.uk.POSTED!not-for-mail
From: Phil Thornley <phil.jpthornley@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Question about Spark_IO
Date: Tue, 10 Apr 2012 17:52:12 +0100
Message-ID: <MPG.29ee756e72e11946989698@news.zen.co.uk>
References: <Cf2dnRYegbnckR_S4p2dnAA@giganews.com>
Reply-To: phil.jpthornley@gmail.com
MIME-Version: 1.0
User-Agent: MicroPlanet-Gravity/3.0.4
Organization: Zen Internet
NNTP-Posting-Host: d3b07d27.news.zen.co.uk
X-Trace: 
 DXC=6mS2@imLPPJL2Ih^^87?RG]G;bfYi23hD=dR0\ckLKG@WeZ<[7LZNRF]j99HRY\X8C6JNOYoB;SJNjAPioiYkWBNOF:Sk5L1WLO
X-Complaints-To: abuse@zen.co.uk
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: 2012-04-10T17:52:12+01:00
List-Id: <comp.lang.ada>

In article <Cf2dnRYegbnckR_S4p2dnAA@giganews.com>, PChapin@vtc.vsc.edu 
says...
> 
> I'm doing something like this to close a file using Spark_IO
> 
>     Spark_IO.Close(Input, Input_Status);
>     if Input_Status /= Spark_IO.Ok then ...
> 
> The Examiner says there is a flow error with the first line because the 
> assignment to Input is "ineffective." This is because it is an 'in out' 
> parameter and nothing is being done with the returned value.
> 
> My understanding is that Close puts the file handle it has been given 
> into an invalid state so that any further use of it will result in an 
> error. Thus it is not correct to do anything with that value after Close 
> returns.
> 
> Is this a case where it is appropriate to suppress the flow error with 
> an '--# accept flow_message...' annotation or is there some better way 
> to handle this situation?

Yes, that's exactly what I would do here.  The File parameter can't be 
changed to 'in' mode - to remove the flow error - as there would be a 
compilation error in the body of Close.

Note that the flow relation on Close doesn't represent the actual flow 
in the procedure and is clearly the closest model that makes any sense.
(It says that the File parameter is set to a constant value - the 
invalid state perhaps - but in the code this setting is conditional on 
the input value of File, so there is actually a self-dependency.)

Cheers,

Phil