aCC vs. ansic

[Ralph Grothe]

Hello,

for a customer's development box we were asked to order and install the HP-UX ANSI C++ compiler (for 11.11 PARISC).
For this product we received a license for which I had had a codeword generated
which enabled me to install all the aCC depots from 11.11 Aplication CDs (CD 1).
Now the developers moan because they are missing anything beneath /opt/ansic.
However, I am convinced that they won't need the ansic anymore as I consider C to be a subset of C++ and thus /opt/aCC/bin/aCC being an adequate replacement for /opt/ansic/bin/cc.
To prove to myself that the aCC can produce executables from a C source I wrote a tiny program that merely lists dirs' contents,
but which uses ANSI-C style formal parameter prototyping which the K/R default HP-UX cc would reject.
Since this little test worked fine I told them that they should invoke aCC rather than cc (or set their env, e.g. CC, appropiately).
I haven't yet tried a larger build (e.g. like Perl from sources) so I cannot tell if I have missed something.
Could it really be that we required an additional license for ansic?
Is there anything which cannot be done with aCC and which would require ansic?

Regards
Ralph

[A. Clay Stephenson]

There is a case in which you need both aCC and ANSI/C but if I could only purchase one, my choice would be aCC. aCC speaks C++ and ANSI/C (but does not understand K&R); ANSI/C speaks ANSI C and K&R C (but not C++); ANSI/C also includes some addional header files that the Bundled C compiler does not. If you have to development in C++, ANSI/C, and K&R C then you need both products. Any production C should have long been converted to ANSI syntax so this shouldn't be an issue.

[Dennis Handly · Accepted solution]

Clay is correct. You are missing some things if you don't have C Developer's Bundle:
HP-UX Developer's Toolkit - X11, Motif, Imake
HP-UX Developer's Toolkit - Imaging
CDE Developer Kit
HP-UX Audio Developer Kit

And under /opt/ansic/:
C Language Analysis Tools

So you also won't have lint.

Other differences in aC++ is that is is typically stricter for C. It doesn't have inline PA assembly support.

For IPF, the C and C++ compilers are exactly the same. There is no lint, use +wlint instead. And the above "kits" are still a difference.

[Ralph Grothe]

Hi Clay, hi Dennis,

thanks for the replies.

I would expect the developers to write ANSI C compliant code,
why I wouldn't care about any K&R idiosyncrasies.
Judging from their applications I would also assume that there should be no need for extra libraries or APIs for audio or Motif stuff.
As for lint (is it some sort of lexical parser?) I think there are plenty OpenSource alternatives (e.g. lex, bison?).
So I am simply awaiting further complaints from the developers should anything vital be missing.
Yet they haven't responded,
so I gather the suffering is bearable.

Rgds
Ralph

[A. Clay Stephenson]

Lint is a tool which looks for discrepancies in the C source but it really only is needed for K&R C. When ANSI/C came along, the function prototypes greatly reduced the need for lint.

Let's suppose we have a function that looks like this:

char *whatever(a,b,c)
int a;
double b;
char *c
{
static char s[512];

(void) sprintf(s,"%d %10.2lf %s\n",a,b,c);
return(s);
} /* whatever */

----------------------------------

Typically in K&R, all you would do is
extern char *whatever();

Notice that there is no listing of the formal paramters of the extern'ed function.

In the calls to whatever, rather than using exactly 3 arguments, you might only use 2 (or 4 or 0) and the compiler would not object. You might use the correct number of arguments but the wrong type; e.g. rather than int,double,string (correct) you might call whatever with double, string, int arguments --- and again, the compiler would not complain.

Lint's job is to look at all of these call's across multiple source files and make sure that the calls are consistant and report any possible problems found.

All of this is not needed because in ANSI/C
extern char *whatever()
becomes
extern char *whatever(int a, double b, char *c);

Now the compiler itself can detect errors related to the number of arguments and their type so that lint is not needed.

At the very least, explain this to your developers and they will think you really know your stuff --- especially if you neglect to tell them where you learned it.

[Ralph Grothe]

Hello Clay,

very kind of you to explain the purpose and usage of lint to me.
Btw, meanwhile I discovered a box administered by colleagues where they have an ansic installation, and there I could
man -M /opt/ansic/share/man lint
to get a terse overview, similar to your explanations.
Having learned this I would say that lint is rather a tool for veteran C diehearts.
By the time when I first took a book about programming C in my hands there had ANSI C been long enough around to have become a de-facto standard (although there were short side notes to depricated K&R style, as far as I remember).
Therefore I think we should have no need for this tool,
come on they demanded us to have a C++ compiler installed,
so I think that any self-respecting C++ programmer who can master something as obscure as C++ grammar should really have no problems switching from K&R to ANSI C ;-)