Path: utzoo!attcan!uunet!samsung!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!umbc3!umbc5.umbc.edu!paulr
From: paulr@umbc5.umbc.edu (Paul Riddle)
Newsgroups: comp.os.os9
Subject: Buggy Microware 6809 C Compiler
Keywords: c bugs microware compiler coco unix
Message-ID: <3583@umbc3.UMBC.EDU>
Date: 8 Jul 90 15:16:11 GMT
Sender: newspost@umbc3.UMBC.EDU
Reply-To: paulr@umbc5.umbc.edu (Paul Riddle)
Organization: University of Maryland, Baltimore County
Lines: 59


Hi everybody,

I was feeling bored yesterday, so I decided to dust off my old Berkeley 2.9BSD
source tape and see how many of the utilities I could get to compile and run
on my CoCo 3 running 6809 OS-9 level 2.  I'm using the original Microware
Level 1 C compiler, with a new compiler driver (cc2) and the Krieder C Library.
I don't know if it's the latest version of the library, I confess I haven't
really kept up with the OS-9 scene lately.  I chose 2.9 over 4.3 because the
2.9 code predates the ancient level 1 C compiler, so I figured I'd have an
easier time getting the code to compile (no void types, etc).

Well, I didn't have to wait too long before I encountered problems; I compiled
'cat', ran it, and my computer locked up.  I was able to isolate the problem
to the following:

#include <stdio.h>

main (argc, argv)
   int argc;
   char *argv[];
{
   FILE *fp;
   if (--argc && (fp = fopen (*++argv, "r"))) {
      copy (fp);
      exit (0);
   }
   exit (1);
}

copy (fp)
   FILE *fp;
{
   int c;
loop:
   c = getc (fp);
   if (c == EOF)
      return;
   putchar (c);
   goto loop;
}

(Note:  It didn't lock up immediately; it ran through about half the file
and then died.  It did this with every file I tried.)

I agree this is twisted (I didn't write the code!), but there is no reason
why it shouldn't work.  I re-arranged the routine a little bit and eliminated
the goto, and it worked fine.

So, my question is:  does anyone have a documented list of nasty little bugs
like this?  I haven't tried the standard Microware C library with the original
code, but I kind of doubt that the Krieder Library is at fault here.  Of
course, I could be wrong.

Thanks,
Paul Riddle                         | paulr@umbc3.umbc.edu
Systems Programmer / Administrator  | ...!{uunet,haven}!umbc3!paulr
UMBC, Computer Science Department   |
Baltimore, MD 21228                 | (301) 455-3962