Re: Get_Line problem (GNAT bug?)

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

Dmitry A. Kazakov wrote:

> I think this is a correct behavior. Here is my explanation of what's going
> on:
>
> When End_Of_File meets a CR (Ctrl-M) it cannot know if this CR manifests
> the end of the current line or both the line end and the file end. This is
> because a file can ends with a CR, and this trailing CR is not counted as
> an empty line. So eventually End_Of_File should attempt to read the
> following character, i.e. block.

No, I don't think this makes sense.  If a disk file contained the
characters M a c i e k <CR> <CR> at the end of the file, then this
should be read in as two lines: one line containing the string
"Maciek", and one empty line.  You're right that this should not be
followed by yet another empty line, but that isn't relevant.  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.  (We
shouldn't be saying CR in any case; Unix uses LF (Ctrl-J) as the line
separator, and Windows uses a CR-LF combination.  We really should just
be talking about "end-of-line" or EOL without referring to any specific
ASCII character.)

And, in any case, if somehow "a trailing CR is not counted as an empty
line" were true, it would be true regardless of whether the program
used End_Of_File to test for end of file, or simply used Get_Line and
relied on End_Error being raised.  So the behavior would have to be the
same in both cases.  But that's not what I observed.

                          -- Adam