eric@mks.mks.com (Eric Gisin) (08/22/90)
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.jgd@rsiatl.UUCP (John G. DeArmond) (08/24/90)
eric@mks.mks.com (Eric Gisin) writes: >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. Pretty much confirms my (rather brief) first impressions of this stuff. The very first impression I got from reading the documentation (gasp!) was that what I had on my hands was a COBOL compiler with the OBOL dropped (grudgingly). That plus the fact that it appeared that they reinvented the wheel at every opportunity make me do an early disk purge. Hmm, seems to me that if ISC would just supply the GNU stuff as their "enhanced" compiler and concentrate their efforts (and our money) on things like fixing the ASY drivers and fixing (or completing) sysadm and fixing mkpart and make the floppy driver catch more than one sector per revolution and so on and so forth, we'd all be lightyears ahead. Anyway, glad to see I'm not the only one underwhelmed by LPI. John -- John De Armond, WD4OQC | We can no more blame our loss of freedom on congress Radiation Systems, Inc. | than we can prostitution on pimps. Both simply Atlanta, Ga | provide broker services for their customers. {emory,uunet}!rsiatl!jgd| - Dr. W Williams | **I am the NRA**
plocher@sally.Eng.Sun.COM (John Plocher) (08/24/90)
eric@mks.mks.com (Eric Gisin) writes: >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. I hope this doesn't sound like an advert for them, but for a real ANSI C compiler under most (all?) versions of Unix you might give MetaWare's Hi-C version 2.2 (or is it 2.3 now?) a try. It does an impressive job (better than SunOS 4.0.3 cc and gcc 1.37), and is much more ANSI compliant than the GNU compiler - it includes all the ANSI req'd libs and header files, etc. They can be reached at 408/429-META Just a very satisfied user... -John Plocher
friedl@mtndew.Tustin.CA.US (Steve Friedl) (08/24/90)
In article <3687@rsiatl.UUCP>, jgd@rsiatl.UUCP (John G. DeArmond) writes: > > Anyway, glad to see I'm not the only one underwhelmed by LPI. On the 3B1 (though several years ago), LPIC was the worst piece of trash compiler I ever used. LPI must be offerring sexual favors to the purchasers of this product, because it surely is not bought for technical merit. ISC, I'm disappointed in you for doing this. Steve -- Stephen J. Friedl, KA8CMY / Software Consultant / Tustin, CA / 3B2-kind-of-guy +1 714 544 6561 / friedl@mtndew.Tustin.CA.US / {uunet,attmail}!mtndew!friedl Q - Why do environmentals like fusion power so much? A - We don't have it yet
friedl@mtndew.Tustin.CA.US (Steve Friedl) (08/25/90)
Previously I wrote: > LPI must be offering sexual favors to the purchasers of this > product, because it surely is not bought for technical merit. I have been informed that I am close but it should be worded differently: LPI customers are getting screwed. Steve :-) -- Stephen J. Friedl, KA8CMY / Software Consultant / Tustin, CA / 3B2-kind-of-guy +1 714 544 6561 / friedl@mtndew.Tustin.CA.US / {uunet,attmail}!mtndew!friedl Q - Why do environmentals like fusion power so much? A - We don't have it yet