Re: TextRider bug on last token

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

>>If this is so then we need to fix Files.C and OakFiles.C. The
>
>For what it's worth, POSIX does not know O_TEXT or O_BINARY.
>Therefore Files.c and OakFiles.c are not broken, nor need to be
>fixed.

As of the B19 release of Cygnus Gnu-Win32, this is the _only_ issue that
prevents the oo2c libraries from working "out of the box" under Windows. I
would therefore suggest something like:

#ifdef O_BINARY
  open_flags |= O_BINARY;     /* use binary mode if it is available */
#endif

at the start of open_file(). Since everything else works so well, it seems
excessive to maintain two versions of the file for the sake of a single
line of code. (No, I'm not much of a fan of #ifdefs either...)

  Then, to
>deal with MS-DOG's CR/LF, the mechanism to "unget" characters must
>be extended to deal with 2 or more characters.

When coding for multi-character symbols, its important to keep in mind that
the file position may advance by more than the number of characters
actually returned. In most cases, this simply means some of extra use of
Pos() and SetPos().

  I believe, MS-DOG
>also has an end of file character (^Z).  Do we need to tackle
>this, too?

As far as I know, ^Z fills much the same function as ^D under unix. That
is, it is universally used to signal the end of input, but is not actually
returned as a character in the input stream.

- Stewart