Re: TextRider bug on last token

[Stewart Smith <ssmith@murdoch.edu.au>]

>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.

If this is so then we need to fix Files.C and OakFiles.C. The underlying
assumption in all C compilers that I have met is that files are opened as
"text" unless otherwise specified. Under Unix it makes no difference, since
text and binary files have the same representation. Under DOS and Windows
(and other operating systems?) if you don't explicity request "binary"
mode, the native end-of-line representation is automatically translated to
/ from the "C" end-of-line representation (LF terminator). For Windows,
this means that CR-LF is translated to LF on all file reads, and LF is
translated to CR-LF on all file writes. This is done at the level of the C
run-time library. Under Unix, "fopen" is part of the C runtime and "open"
is part of the OS API. On other operating systems, "open" is also part of
the C run-time and will do this kind of translation. Unless you hard-wire
O_BINARY into all file-open functions, any attempt to do binary I/O will
fail on these types of systems. This is what I had to do to get OO2C
running under Windows. Since we are agreed (?) that Channels are
uninterpreted, any channel MUST be opened as O_BINARY (for Unix this should
have no effect anyway).

- Stewart