Xref: utzoo comp.unix.i386:6303 comp.unix.xenix:12239
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!iphase!floydf
From: floydf@iphase.UUCP (Floyd Ferguson ENG)
Newsgroups: comp.unix.i386,comp.unix.xenix
Subject: Re: Xenix vs. UNIX
Summary: Problems with SCO rcc (real cc??)
Message-ID: <223@iphase.UUCP>
Date: 28 Jun 90 23:22:48 GMT
References: <3304@crash.cts.com> <4716@thebes.Thalatta.COM> <1990Jun27.232700.3046@virtech.uucp>
Reply-To: floydf@iphase.UUCP (Floyd Ferguson ENG)
Organization: Interphase Corp. Dallas TX
Lines: 53

Article 6254 of comp.unix.i386:
Path: iphase!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.i386,comp.unix.xenix
Subject: Re: Xenix vs. UNIX
Message-ID: <1990Jun27.232700.3046@virtech.uucp>
Date: 27 Jun 90 23:27:00 GMT
References: <3304@crash.cts.com> <4716@thebes.Thalatta.COM>
Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill)
Organization: Virtual Technologies Inc., Sterling VA
Lines: 27
Xref: iphase comp.unix.i386:6254 comp.unix.xenix:8544

In article <1990Jun27.232700.3046@virtech.uucp>cpcahil@virtech.uucp (Conor P. Cahill) writes:
> SCO UNIX (with its inclusion of the standard AT&T compiler) should alleviate
> many of these problems.

In my opinion the C compiler situation in SCO is THE most unsatisfactory
part of the package. Including rcc (Real C) barely makes up for the 
inadequacies of the default Microsoft compiler, and SCO has not taken
any pains whatsoever to ensure that rcc is actually usable.

While I've successfully compiled gcc and xemacs with rcc, gdb would not go,
and a couple of the guys here have had a _terrible_ time getting some
application code to port. I've not been able to get the MickeySoft compiler
that SCO packages as cc to come even close to handling xemacs.

There are three problems that either I've run into myself, or have been
encountered by a couple of the guys here who've done a whole lot more at the
application level than I have:

1. SCO has butchered a lot of the header files, which must be unbutchered
before rcc will eat them. rcc knows nothing of void, which is liberally
sprinkled through the header files. I also seem to remember running 
into some function prototypes that caused rcc to barf.

2. Structure assignment does not work, but does this silently (at least
until you blow the stack frame assigning a structure to something with
auto storage.

3. memcpy does not work. Actually, it fails to set the direction flag,
so sometimes memcpy's backwards!

Actually, there are three compilers: rcc, cc (Microsoft), and some stripped
down version they use to build the space.o modules in the kernel. All three
have a different idea of structure alignment! which has caused some very
entertaining bugs when allocating storage for drivers in the space.c
module.

Overall, if I had to any serious application development the first thing
I would do would be to get gcc running. 

floyd ferguson -- uunet!iphase!floydf