Re: End_Of_File but not really

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

Adam Beneschan wrote:
> 
> If I try this on Linux, on a file whose bytes are abc<LF><LF>, then the
> message "End_Of_File returned TRUE but Get_Line did not raise an
> exception".  This strikes me as bizarre---if End_Of_File returns True,
> then a subsequent read operation should raise an End_Error, but that
> isn't what's happening.  One of these must be true:

This is the behavior I described in an earlier post.

 From a Text_IO point of view, this is a degenerate file, since it 
doesn't end in <EOL><EOP><EOF>. But consider if you wrote this file with 
Text_IO:

File : Ada.Text_IO.File_Type;
...
Ada.Text_IO.Create
    (File => File, Mode => Ada.Text_IO.Out_File, Name => "f1");
Ada.Text_IO.Put_Line (File => File, Item => "abc");
Ada.Text_IO.Put_Line (File => File, Item => "");
Ada.Text_IO.Close (File => File);

Then you would get what Text_IO considers a correct text file, containing

abc<EOL><EOL><EOP><EOF>

(however those are encoded for your OS/compiler). After the first 
Get_Line, the remainder of the file contains <EOL><EOP><EOF>--the 
definition of the condition when End_Of_File returns True. Yet clearly 
there is an empty line still to be read in that file, since it was 
created by writing "abc" followed by writing an empty line. So the 
situation you describe is true even for a file written by Text_IO: 
End_Of_File returns True and Get_Line reads an empty string.

Another way of looking at it: End_Of_File looks ahead and sees 
<EOL><EOP><EOF>, so it returns True. Get_Line reads <EOL>, so it sets 
Last to Item'First - 1 and returns.

I'm not saying this is sensible, just that it's what the RM specifies. 
Text_IO would be better without pages, and without column and line (and 
page) counting.

-- 
Jeff Carter
"Every sperm is sacred."
Monty Python's the Meaning of Life
55