[comp.lang.c] LPI-C, why?

larry@focsys.uucp (Larry Williamson) (07/16/90)

ISC's new 2.2 release comes with a C compiler from LPI.  The
introduction in the manual does not give much of an excuse to use this
new compiler. 

Some 'features' mentioned in the manual are ...
. Standard libraries and header files are included.
. Function prototypes are supported.
. Compile time string concatenation is provided.
. New preprocessing directives including stringize, token-paste,
  #elif, #error and defined()
. inline code generation for some functions
. const and volatile type qualifiers
. auto initialization of aggregate types
. void * supported
. can call functions written in other LPI languages
. annotated listing output with user symbols, cross reference and
  summary of compile stats
. works with code-watch (an interactive debugger).

And to top it all off, if you decide to use this new compiler, then
you get to use the (much nicer) command lpicc, instead of just plain
ol' cc.

Does not sound too exciting to me.

Did I just pay too much for the SDS (Software development system)
package? :-|
Or is ISC giving out a frebie here?

-Larry

karl@haddock.ima.isc.com (Karl Heuer) (07/17/90)

In article <LARRY.90Jul16161846@focsys.uucp> larry@focsys.uucp (Larry Williamson) writes:
>ISC's new 2.2 release comes with a C compiler from LPI.  The
>introduction in the manual does not give much of an excuse to use this
>new compiler.

Plain cc is more or less as it's always been; lpicc is intended to be ANSI
compliant.  I imagine some customers have ANSI C programs they'd like to be
able to compile.

>Does not sound too exciting to me.

If you're not interested in ANSI C, then by all means keep using the old one.
That's why we ship it under a separate name instead of just overwriting cc.

Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
(I'm not speaking for ISC, of course.)

peter@ficc.ferranti.com (Peter da Silva) (07/17/90)

In article <17097@haddock.ima.isc.com> karl@kelp.ima.isc.com (Karl Heuer) writes:
> If you're not interested in ANSI C, then by all means keep using the old one.
> That's why we ship it under a separate name instead of just overwriting cc.

Shouldn't that name be "c89"?
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.
<peter@ficc.ferranti.com>

gsteckel@diag2.East.Sun.COM (Geoff Steckel - Sun BOS Software) (07/18/90)

One major complaint/warning about LPI C:
   The call/return sequence for return of structure values from functions
is documented to be INCOMPATIBLE with ATT cc.

Why?  This would seem to be a bug, not a feature.  Any comments from ISC
on why they sell an incompatible C compiler?  This single incompatiblity
means that you cannot safely intermix modules compiled with the two compilers.
I don't use structure return values often, but I have NO idea whether or
not any random module I've inherited does, and if it's a library, have
NO WAY to find out.

LPI C also seems not to produce better code than the ATT compiler, at least
on the 10 or so programs I ran through it.

I bought the development kit but don't use LPI cc.  I use GCC if I need
an ANSI C compiler.  It can be forced to generate compatible code.
$700 wasted.

	regards,
	geoff steckel (gwes@wjh12.harvard.EDU)
			(...!husc6!wjh12!omnivore!gws)
Disclaimer: I am not affiliated with Sun Microsystems, despite the From: line.
This posting is entirely the author's responsibility.