Re: Get_Line problem (GNAT bug?)

["Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org>]

Adam Beneschan wrote:
> 
> However, I still don't think it should return True here.  The concepts
> of line, page, and file terminator are logical concepts whose actual
> representation is defined by the implementation (A.10(7-8)); it's not
> correct to simply assume that <CR> (or <LF> or <CR><LF>) is equivalent
> to a line terminator in all cases.  A.10(7) says that the end of a file
> is marked by the combination of a line terminator, a page terminator,
> and a file terminator.  I would hope that in the above case, the
> logical end-of-file is considered to be a line terminator followed by a
> page terminator followed by a file terminator; the line terminator and
> page terminator here would be implicit, and would not be represented by
> any actual bits in the disk file, but would be logically considered to
> be present.  Thus, after Get_Line reads the first string, "Maciek", the
> next things would be a line terminator (represented by the second <CR>)
> followed by *another*  line terminator (implicit, not represented by
> anything in the disk file) followed by a page terminator (also
> implicit) followed by a file terminator (also implicit); thus,
> End_Of_File would return false.

I believe there's a permission somewhere in an AI that any or all of the 
final line, page, and file terminators may be missing, to handle text 
files not written by Ada, and many non-Ada programs that write text 
files will end with a line terminator; Ada is allowed to (and should) 
interpret that as both an EOL and an EOF, just as it interprets 
<EOL><EOP><EOF>.

Things are especially messy when reading standard input, because Text_IO 
assumes that look ahead is possible, and with standard input, it isn't.

So, if a text file (not standard input) contained

xyz<EOL><EOL>

after a Get_Line you'd have eaten

xyz<EOL>

and both End_Of_Line and End_Of_File should return True.

However, for standard input, as Kazakov said, End_Of_File doesn't know 
if this 2nd <EOL> is the last thing in the "file". So it has to wait for 
more input to be buffered before it can return. There are three cases:

1. The input is <EOF>. End_Of_File returns True.

2. The input is <EOP>. End_Of_File has to wait for more input.

3. The input is anything else. End_Of_File returns False.

> Somebody please correct me if I'm wrong.  If I'm wrong, though, and the
> RM requires the behavior I'm seeing, then the RM doesn't seem to make
> sense.

It comes from the need to handle files created by Text_IO (<EOL> is part 
of the file terminator) and by non-Ada programs (no file terminator).

-- 
Jeff Carter
"People called Romanes, they go the house?"
Monty Python's Life of Brian
79