dyer@spdcc.COM (Steve Dyer) (04/28/87)
Goodness knows there are enough things to complain about with the 286 chip
and the XENIX 286 C compiler and libraries that attempt to use it, especially
when you try to use the 286 large and huge memory models.
However, the use of the (very common) constructs:
char *charp;
if (!charp)
or
if (charp == NULL)
is NOT one of them; they work fine.
Having wrestled now with SCO XENIX for more than a year, bereft of sources,
I suspect the the original poster had a fit of paranoia; after trying to get
anything to run on this machine, you begin doubting your tools, your choice
of memory models, and finally your own understanding of the C language
itself! Be kind... :-)
News 2.11 patchlevel 8 runs just fine on SCO XENIX. Interested parties can
get it from my machine:
spdcc Any ACU {1200,2400,300} 16176614927 login: uucp
uucp spdcc!~uucp/compress compress (12-bit compress)
uucp spdcc!~uucp/sconews.tar.Z .
ln compress uncompress
uncompress sconews.tar
I haven't turned this into a set of diffs between standard 2.11 patch 8
and this distribution, mainly because I haven't had the time. The only
XENIX-specific changes are in the System V locking code which needed to be
changed to use XENIX locking, because as implemented under SCO XENIX,
System V locking is enforced against ALL processes, and not just those
which use the lockf system calls. This means that locking the ACTIVE
file (as during expire) loses. This is clearly wrong according to the
SVID and all other System V implementations, but they passed the SVID
test, so therefore it's OK (or so they say...) There's a file called
XENIXCHANGES in the src subdirectory which explains what I did.
--
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,halleys}!spdcc!dyer