5.13.4 The Last Line of a Stream
How to handle the last line in a stream is sometimes a problem. If
you use a system that stores end-of-lines as special character
sequences, and the last part of the data of a stream is an
unterminated line, then what is returned when you try to read that
part of data?

There are three possible solutions: First, it may interpret the
end-of-file itself as an implicit end-of-line, in this case, the
partial part of the line is returned, as if it was properly
terminated. Second, it may raise the NOTREADY condition, since the
end-of-file was encountered during reading.  Third, if there is
any chance of additional data being appended, it may wait until
such data are available. The second and third approaches are
suitable for persistent and transient files, respectively.

The first approach is sometimes encountered. It has some problems
though. If the end of a stream contains the data ABC<NL>XYZ, then
it might return the string XYZ as the last line of the stream.
However, suppose the last line was an empty line, then the last
part of the stream would be: ABC<NL>. Few would argue that there
is any line in this stream after the line ABC. Thus, the decision
whether the end-of-file is an implicit end-of-line depends on
whether the would-be last line has zero length or not.

An pragmatic solution is to let the end-of-file only be an
implicit end-of-file if the characters immediately in front of it
are not an explicit end-of-line character sequence.

However, TRL gives some indications that an end-of-file is not an
implicit end-of-line. It says that LINES() returns the number of
complete lines left, and that LINEIN() returns a complete line.
On the other hand, the end-of-line sequence is not rigidly defined
by TRL, so an implementor is almost free to define end-of-line in
just about any terms that are comfortable. Thus, the last line of
a stream may be a source of problem if it is not explicitly
terminated by an end-of-line.


 PREV   NEXT