Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!usc!ucsd!pacbell.com!pacbell!att!watmath!mks.com!mks!eric
From: eric@mks.mks.com (Eric Gisin)
Newsgroups: comp.unix.i386
Subject: LPI C review
Message-ID: <ERIC.90Aug22173559@mks.mks.com>
Date: 22 Aug 90 16:35:59 GMT
Sender: eric@mks.com (Eric Gisin)
Distribution: comp
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
Lines: 51

I use the System V.3 C compiler and GNU C all the time.
I recently compiled several thousand lines of C with LPI C.

All of this code compiles with "gcc -ansi" with no warnings.
This is a prerequisite for portable code, especially when
compiling with a non-DOS ANSI C compiler. Most ANSI compilers
treat some of GCC warnings as fatal errors.

All the code (18,000 lines) compiled with LPI C with two exceptions.
One was where pointer arithmetic was attempted on a (void*).
This is not legal, and GCC 1.36 does not give a warning for this.
The other seems to be a compiler bug. The code in the application
looked like this, but this compiles and the application doesn't.
	typedef char v2[2];
	void f(v2 v);
	void f(v) v2 v; {}
Using a prototype function definition made it compile.

One 2000 line program I built with LPI C worked fine.
Another 15000 line program (shell) worked for some tests
but died when used interactively.  I got a SIGSEGV when
strlen was passed a garbage pointer. I did not investigate further.
The run time startup sets up default signal handlers, but
they do not reissue the signal so you don't get a core file.
The handler prints something like (yech):
	*** Condition ERROR raised.
	*** Unhandled signal SIGSEGV, PC=...

We don't have GNU C on System V/386,
so I will compare the performance of LPI C against AT&T C.
I will note that the size of the one-pass LPI compiler is
larger than all three passes (cpp,cc1,gas) combined
of the 68000 version of the GNU compiler.

The cpu and real times of "lpicc -O" are twice that of "cc -O".
The object file text sizes are 20% larger for LPI C.
When compiling with -g, the times are four times that of "cc".
And with -g, the text segments are twice as large.
They add lots of "nop"s for unknown reason (its not alignment),
and seem to put debugging information in the text segment.
The LPI .o files are minimally COFF compatible;
they will link with "ld" but have no COFF debugging information.

I won't be using LPI C anymore, I will just install GNU C whenever I find time.

PS.
The defintion of offsetof in stddef.h doesn't work with AT&T or LPI C.
Use this instead:
	#define	offsetof(type,id) ((size_t)&((type*)NULL)->id)

		Eric Gisin, Mortice Kern Systems, Inc.