Re: Get_Line problem (GNAT bug?)

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

Björn Persson wrote:
> Adam Beneschan wrote:
> > After the
> > first Get_Line has consumed the characters M a c i e k <CR>, then, when
> > End_Of_Line looks ahead and sees that the next character is <CR>, it
> > should be able to return False immediately without needing to look
> > ahead to see whether <CR> is immediately followed by EOF.  And I don't
> > see why this wouldn't apply to an interactive file as well.
>
> I agree that that's how it should be, but it's not how End_Of_Line is
> defined: "Returns True if a file terminator is next, or if the combination
> of a line, a page, and a file terminator is next; otherwise returns False."

I meant to type End_Of_File.  But  End_Of_File is defined the same way:
it returns True if the combination of a line, a page, and a file
terminator is next.  (A.10.5(25))

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.

This is all implementation-dependent.  However, I'd consider that if an
implementation would return two strings for Get_Line ("Maciek" and "")
and raise End_Error only the third time Get_Line is called, but would
return True for End_Of_File after just the *first* Get_Line, then the
implementation would be in error since it isn't consistent.  You may be
able to interpret the RM in a way that would make this permissible, but
the unwritten rule is that implementations are supposed to act
sensibly, and this would not make sense.  (By the way, the behavior
that I believe makes no sense is also how GNAT is acting when reading
from a file opened with Open, rather than standard input.)

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.

                            -- Adam