Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!uunet!ncrlnk!ncr-sd!crash!pnet01!jca
From: jca@pnet01.cts.com (John C. Archambeau)
Newsgroups: comp.os.minix
Subject: Turbo C 1.5 Revisited...
Message-ID: <4105@crash.cts.com>
Date: 23 Apr 89 17:36:24 GMT
Sender: news@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 35

I have found the problem with it and it turns out to be a nasty bug in the
object code generator for switch statements.  If you compile with the -S
option, the assembly code looks perfectly legal (it probably is), but if you
take a debugger to the generated code for fsck.c, it turns out that the switch
code does not match that (operand wise) to the assembly code.
 
I have a sneaking suspicion that there are such beasts as Turbo C 1.51, 1.52,
etc. floating around out there with patches that Borland has put in.  It's the
only logical explanation as to my problem in building Minix with 1.5.
 
For you Turbo C 1.5 people who have successfully built Minix without this
problem, did you have to patch your compiler for it to work?  
 
For those of you trying to cross compile with 1.5 and for some strange
bizarre reason commands you get with the opening menu are illegal, try adding
this debugging code to default in main of fsck.c
 
 default:
  if (command == '=')
   printf ("\nEeek!  Time to yell at Borland.\n");
  printf ("Illegal command.\n");
  continue;
 
If the switch code was working properly, the first printf after the if in
default should NEVER be printed since there's a case '=' which is used to
start up the kernel.
 
(Oh, thanks to that person who sent me mail saying that it might be a bug with
TC, but I didn't want to believe it...now I believe it.)
 
 JCA

UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca
ARPA: crash!pnet01!jca@nosc.mil
INET: jca@pnet01.cts.com