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,INVALID_DATE,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucsd!helios.ee.lbl.gov!pasteur!tully.Berkeley.EDU!hilfingr
From: hilfingr@tully.Berkeley.EDU (Paul Hilfinger)
Newsgroups: comp.lang.ada
Subject: Re: TEXT_IO anomality
Message-ID: <26496@pasteur.Berkeley.EDU>
Date: 26 Jul 90 06:54:29 GMT
References: <9007241309.AA00417@ajpo.sei.cmu.edu> <2020@cod.NOSC.MIL>
Sender: news@pasteur.Berkeley.EDU
Reply-To: hilfingr@tully.Berkeley.EDU (Paul Hilfinger)
Organization: Lawrence Livermore National Laboratory
X-Local-Date: 25 Jul 90 23:54:29 PDT
List-Id: <comp.lang.ada>



|>
|>>2. When doing a Get_line, the user terminates input by pressing <CR>.
|>>   This moves the screen cursor to Col 1 of the following line (and
|>>   the COL counter of STANDARD_INPUT is updated accordingly).  Still,
|>>   the COL counter of STANDARD_OUTPUT remains as before.
|>
|>     Very interesting.  I've verified that VAX Ada behaves the same way.
|>In a quick skim through the LRM I saw nothing that explicitly required
|>this behaviour.  (It could be there and I just missed it.)  In section
|>14.3.5 (3) is the statement "All procedures GET and PUT maintain the
|>current column, line, and page numbers of the specified file: ...".  I
|>wonder if implementors have jumped to the conclusion that only these
|>procedures, along with SET_LINE and SET_COL, can affect those numbers?
|>In looking at the titles of the 800+ issues considered by the ARG, it
|>appears that this question has never come up.  In the absence of an
|>explicit requirement to the contrary, I consider this to be a misimple-
|>mentation.  If your cursor is blinking at column 40 and you ask what
|>the column of STANDARD_OUTPUT is, any answer other than 40 is wrong.
|>(Even in the presence of an explicit requirement any answer other than
|>40 is wrong, but it just might not be possible to fix it.)
|>
|>                              Charlie Sampson
                                      
Leaving aside the question of whether the behavior is desirable, it is 
definitely correct.  14.3(6) indicates how terminators may find their way
into a file; it only mentions operations on the file itself (and "file",
by the way, always means "internal file" in this chapter, not "external
file", such as the actual contents of one's screen).  14.3(8) indicates
that it is these terminators that are counted when determining the value
of LINE---regardless of any other effects on the external file. 
14.3.5(3) indicates that GET, PUT, etc., maintain the column, line, and
page numbers of the "specified file", and not some other random file
unmentioned in the statement.  Finally, the Note 14.1(13) indicates that
the effect of sharing the same "bidirectional" device between several
file objects is implementation-dependent.

Furthermore, I think that changing the behavior of TEXT_IO to take
account of interactions between input and output on a terminal would be a very
bad idea.  It would mean, one presumes, that the runtime system would have
to maintain implicit links between files that read and write from 
terminals; that every write to a terminal would involve first checking
for input from the terminal (so as to get the correct final values for
LINE and COL); and a few other implications I have undoubtably missed.

Paul N. Hilfinger, (member ARG, URG, and Ada 9X Distinguished Reviewers)
Computer Science Division				
Dept. of Electrical Engineering and Computer Sciences
University of California
Berkeley, CA  94720
Hilfinger@Berkeley.EDU
(415) 642-8401