Re: End_Of_File but not really

["Randy Brukardt" <randy@rrsoftware.com>]

"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.

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.

                              Randy.