TextRider bug on last token

[Michael van Acken <KK120y2@mail.lvr.de>]

IR> 1.  There appears to be a bug in TextRider.ReadLInt().  If the
integer
IR> token has no other characters following it in the input stream,
the
IR> token is not read and "reading past end of input stream" error is
IR> returned.
IR> 
IR>  Here is the code:
IR> 
IR>     (* accumulate the digits *)
IR>     WHILE (r.byteReader.res=done) & CharClass.IsNumeric(str[pos])
DO
IR>       INC(pos); r.ReadChar(str[pos])
IR>     END;
IR> 
IR>     (* convert to an integer *)
IR>     IF r.byteReader.res#done THEN RETURN END;   <== Give up if at
end of
IR> input. Wrong.
IR>     r.UngetChar(str[pos]); str[pos]:=0X; 
IR>     IntStr.StrToInt(str, lint, res);
IR> 
IR> I downloaded 002c 1.3.7 but couldn't find TextRider.Mod.  Perhaps
this
IR> bug has been fixed since ooc 1.13?

TextRider.Mod is in subdirectory lib, and the module's source code is
also installed in the installation directory (in <prefix>/oo2c/lib/).

The problem is related to the lookahead by one character implemented
by TextRider.  When backing up one char, the error code needs to be
backed up, too.  I will look into this.

IR> 2. A small change request for Channel.Mod.  Please add the
following field:
IR> 
IR> eolType-: INTEGER;
IR> (* Type of end-of-line char(s) this channel has.
IR> 0=lf, 1=cr/lf, 2=cr.
IR> *)

I am sorry, but this is not possible.  A channel is defined as a
sequence of uninterpreted bytes.  It has no concept of "lines", nor
of
"end of line" characters.  The same is true for all implementations
of
Channel and all binary riders.  Therefore I cannot introduce this
alien concept at this level.

The field must be made an attribute of text riders.

IR>    This is necessary because my portable text i/o library
supports
IR> several types of channels.  The BBox implementation supports
Files and
IR> Texts (the Bbox text object).  These have different eol
characters:
IR> cr/lf and cr respectively.

These are not different types of channels, but rather different
interpretations of them, at least in the frame of definitions used by
the OOC lib.  Bbox might see this differently.  On the other hand,
OOC's IO libs were mostly inspired by Oberon/F, so I would be very
surprised if they broke their own layering concept.

IR>    TextRider needs to be able to sense and generate eol chars for
any
IR> Channel.  There is no other place to put this information except
IR> Channel.Mod.

Sorry, but Channel.Mod is the wrong place to put this.  You need to
find another way.

-- mva