Lattice/UNIX incompatibility

[Kaare Christian]

When I originally entered my note on csd, I didn't expect one
small paragraph near the end to generate so much discussion.  The
oft quoted paragraph started by praising Mark Williams C compiler
for its Unixisms, and then I made an offhand remark about Lattice
C and its seemingly lower level of Unixness.

My thanks to ark at Alice for his list of four Lattice non-standards. I
agree with him that all four of those problems make it hard to
port Unix software to the PC using Lattice C.  The third problem,
Lattice's requirement for the extern phrase in all but one global
declaration, has generated the most controversy.  Lattice may be close
to what is spelled out in K+R, but it is clearly not the way Unix C
works and it certainly makes it hard to port Unix code to the pc.

My experience using Lattice C is NIL.  I have only looked at the
manual.  I do know someone who tried porting a Venix
application to the PC using Lattice.  He encountered problems.
The same application ported effortlessly using Mark Williams
compiler, including the assembly language in-lines.

Here are some additional rough spots in Lattice C that I have gleaned
from the Lattice C manual.

	5. No struct/union assignments.  This isn't mentioned in
Lattice's list of differences.  Struct/unions became full fledged
data objects (unlike arrays) several years ago.

	6.  In their list of differences, Lattice notes that they
use separate name pools for the members of each struct/union.  I
know that this is different from K+R, but it has been an accepted
upgrade in the Unix/C world for some years.

	7. Identical strings are stored together.  (I doubt that
this would cause many problems.)

	8. If a is an array, Lattice construes &a to be a pointer
to an array, not a pointer to the first element in a.  Most Unix
compilers take &a to mean the same thing as a itself - a pointer
to a's first element, not a pointer to an array. The type is
wrong, but the value is correct.

	9. The currency symbol is allowed in identifiers.

	10. Pre processor macros with arguments are limited to a
single line.  This is what the manual says. I don't know if you
can escape the newline as is routinely done in Unix versions of C.

	11. The open and fopen system calls must be told if you want to
treat the file as a binary file.  The default is to assume an ASCII
file, with disastrous consequences for many programs.  PCDOS knows
(exactly) the size of each file. Only a few programs use a Ctrl-z to
delimit the end of file - why bother.  There is at least one word proc
for the pc that delimits the text with a Ctrl-z and then places some
(binary) status info following the fake eof.  Ctrl-z as an eof for text is a
throwback to cpm/80 and it isn't necessary, or widely used in the pc.
I think the default for read (and probably for fread) should be
to give the programmer the data, raw and uninterpreted.

	12.  Multiple character constants (e.g. 'aa') (stored in ints or
longs) are allowed.  This feature probably shouldn't be used if
you want to port programs from Lattice to the real world, but I
doubt it would make it harder to port from real to Lattice.

And finally, let me note one peculiarity.  The modern Unix open
statement takes three arguments; the third is an access mode that
is used when the file is created.  Lattice's open doesn't accept
the third argument - this makes sense on pcdos because there
aren't any file access modes.  However the creat system call does allow
the mode argument, its meaning is supposedly explained in the
citation for open.

Lattice C looks like a good product for developing software on the
pc.  It certainly has a better price that Mark Williams, and many
netlanders are very happy with it.  I'm not trying to argue that
it is junk, I'm only noting some of its limitations.

My Mark Williams C manual is at home.  I'll post its advertised
shortcomings in a later note.

Kaare Christian		uucp:cmcl2!rna!kc