Re: End_Of_File but not really

["Adam Beneschan" <adam@irvine.com>]

Randy Brukardt wrote:
> "Adam Beneschan" <adam@irvine.com> wrote in message
> news:1165514423.562024.70510@j72g2000cwa.googlegroups.com...
> ...
> > (2) This behavior is what the RM requires.  To me, this means the RM is
> > broken---it just doesn't make sense to me that End_Of_File would return
> > True if there is more information in the file to get with Get_Line
> > (even if the information is "the presence of a blank line").  But
> > perhaps it's my own understanding that is broken; perhaps my
> > understanding of what End_Of_File is supposed to do is wrong, even
> > though I think it's what a reasonable person would expect a function
> > called "End_Of_File" to do.
>
> This is exactly the state. It's the way these things were defined in Ada 83,
> and required by the ACATS since the very begining. I'd be very surprised if
> you found any Ada compiler that doesn't have this behavior (didn't you try
> it on your compiler to cross-check)?

> As I noted before, there is absoletely no chance that this behavior (or any
> behavior of Text_IO) would be changed, because there's no possible way for
> such a change to the compatible. If the program "knows" about the "lost"
> blank line, it might fail badly if the definition was to be changed. So it's
> 23 years too late to fix Text_IO.

OK, this is the sort of clarification I was looking for.  I was under
the impression that, since the definitions of the terminators were left
up to the implementation, it would be possible for an implementation to
define them in a way so that things would work "correctly" (i.e. in a
way that would make sense to me).  But I guess that's not possible, or
in any case implementations aren't expected to do this.  Thanks.


> The moral is simply to never use Text_IO.End_of_File, but rather handle
> End_Error instead. If you try to use End_of_File, you have the potential of
> "losing" the last line of the file, you still can have End_Error raised if
> you call Get or Get_Line when there is no <LF> character at the end of the
> file, your program will run slower, and your program won't be able to read
> interactively from the keyboard. It's not worth it, no matter what you think
> about using exceptions for non-errors.

It might have made sense to provide a version of Get_Line with an
"End_Of_File" OUT Boolean parameter; this version would behave exactly
like the other Get_Line except that it would set this parameter to True
instead of raising End_Error.  That would have satisfied people who
don't like exceptions, while avoiding the hokey semantics of the
End_Of_File function (and not requiring Text_IO to do any lookahead).
Of course, anyone can easily write their own version of Get_Line that
works like that.  I agree that, based on the discussions in this
thread, the Text_IO.End_Of_File function should just be avoided.

                                 -- Adam