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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,e89e4fc8b5c5f198
X-Google-Attributes: gid103376,public
From: Dale Stanbrough <dale@goanna.cs.rmit.edu.au>
Subject: Re: get_line
Date: 1998/06/06
Message-ID: <6lbg7h$nnv$1@goanna.cs.rmit.edu.au>#1/1
X-Deja-AN: 360125200
Distribution: world
Content-Transfer-Encoding: 8bit
References: <Pine.OSF.3.95.980605111447.22858A-100000@esus.cs.montana.edu>
Content-Type: text/plain; charset=ISO-8859-1
X-XXMessage-ID: <B19F817B9F011B17@obibicut.cs.rmit.edu.au>
Organization: RMIT
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1998-06-06T00:00:00+00:00
List-Id: <comp.lang.ada>


Samuel Mize writes:

"Get_Line stops reading if you ran out of space in your string buffer. 
So,
 you need to check for that, and call Skip_Line:
 
       Get_Line (S, Last);
       if Last = S'Last then
         Skip_Line;
       end if;
 
 You could put this into a procedure, that will then behave as you
expected
 Get_Line to do.


Well, no, not quite always. If there are the exact number of characters
in the input as will fit in the string, then it will automatically skip
the end of line. The code above would then skip the following line as
well.

The solution is to read the characters in char by char. It is
unfortunate that Get_Line has such a weak postcondition.

Dale