Re: ooc-980713 & oo2c-1.3.8

[Michael van Acken <mvacken@t-online.de>]

> From: "Eric W. Nikitin" <enikitin@apk.net>
> Date: Fri, 24 Jul 1998 09:00:57 -0400 (EDT)
> 
> Ian Rae <ianrae@istar.ca> wrote:
> > 1.3.8 works fine for all 3 eol types.
> >
> > one small gripe:
> > ReadLine returns readAfterEnd on the last line of a text
> > file if no eol exists for that line.  Since there is generally
> > no guarantee of eol on the last line, especially for user-
> > created files (it just depends whether you hit enter or not
> > after typing the last line), this behaviour is a bit odd.
> > Certainly gets() in C has more forgiving logic: "read until
> > eol or eof".

This can be attributed to the scanner logic of TextRider, and the urge
of ReadLine to consume the eol sequence.  If there is no eol sequence,
it does make sense to flag it as an error.

Besides, ReadLine has to return a `readAfterEnd' sometime, or it will
get stuck at the end of the file indefinitely.  The only alternative I
see is to have it return this error only if the last line is empty.
That is, an input like

line1<eol>
line2<eof>

would return

  str="line1", Res()=done
  str="line2", Res()=done
  str="", Res()=readAfterEnd

instead of

  str="line1", Res()=done
  str="line2", Res()=readAfterEnd

BUT: This does not solve the problem, because one cannot decide if the
last empty result is correct user input, or indeed an error.

> [...]
> However,
> 
> > This isn't a huge issue.  I can live with it since the implementation
> > still returns the last line, but perhaps this issue should be put
> > on a wish list and if lots of people raise it, then fix it in a later
> > release.
> 
> (1) says that there is no valid way to read the last line if it is not
> terminated by an EOL (even though, in the current implementation, S does
> contain the value of the last line).  IMO, the spec should be changed to
> 
> 
> Method: `(R: Reader)' ReadLine `(VAR S: ARRAY OF CHAR)'
>      Reads a sequence of characters into S; reading continues until an
>      end-of-line character is encountered, the array S is full, or R reaches
>      the end of the channel.  The end-of-line character is discarded and S
>      is always terminated with `0X'.
> 
>      If R is already positioned at an end-of-line character, 
>      S returns as an empty string.
> 
>      If S is not large enough to hold the entire input, a
>      `valueOutOfRange' error occurs; S returns with the sequence of
>      characters that have been read so far (terminated by `0X').
> 
>      If R has already reached the end of the channel (i.e., there are no
>      more characters left to read), a `readAfterEnd' error occurs and S
>      returns as an empty string.

I agree with Eric.  The specs should be changed like this to cover the
end of file case.

-- mva