[Coco] Curses, foiled again!

[Paul Fitch]

> Looking it over, I did find one more problem:  Both curses.c and
> curses.h end without a final newline.  
> 
> This is a problem for OS-9 because the readln system call, used to
> read ASCII type files, won't return anything unless it finds a
> newline.  If it finds the end of file without a newline, it simply
> returns the eof. :-(
> 
> This means that curses.c effectively ends without a #endif to match
> the #ifdef MAIN... and curses.h doesn't actually define wscroll(). :-(
> 
> OK, since this sort of thing is a major pain to fix in OS-9, I've put
> a new version of the archive up on
> http://www.sdc.org/~goosey/os9/curses.lzh
> with the eol problem fixed.
> 
> This isn't actually a bug in OS-9.  It's documented, after all. ;-)
> The OS was carefully written this way.  Really, this only shows up
> with text files imported from other machines with sloppier
> conventions.
> 
> Which is really making me wonder about this curses package.   Except
> for the newlines, which are proper OS-9 cr's, it doesn't look like an
> OS-9 source file.  I wonder if that Waggoner d00d was using a cross
> compiler on a Mac or Amiga?
> 
> Either that, or I'm wondering if some versions of lha don't hack off
> terminating newlines.
> 
> >because when I run the C Beutifier like this --> cb <curses.c
> >>curses.cb it crashes the emulator.  The ident on CB shows a good
> >CRC.
> 
> Can't help you there, never used it.

I knew I wasn't going nuts<g>.

All cb is supposed to do is take a C file and do some formatting to it to
make it more readable.  Match up braces, etc...  But with the missing final
newline, that might have been why it was crashing.  I haven't looked at the
cb src in a few days, but I suspect its looking for the EOF to tell it to
stop, and when it doesn't it continues on in some sort of RAW mode, which
has it reading other stuff not part of the file.