porting c programs from alpha to IA64

[Craig A Berry]

> we compiled all our programs with /warning=warning=all/check=all. 

> With these qualifiers, thecompiler did not find anything suspect.

From HELP CC/WARN

"The default qualifier, /WARNINGS, enables all warning and informational messages for the compiler mode you are using."

From HELP CC/STANDARD:

"Defines the compilation mode."

The good that you did with your choice of /warnings you undid with your choice of /standard=vaxc, which is what the compiler calls "compilation mode."  Here's a handy example of K & R C I found on the net:

$ type try.c
long some_function();
/* int */ other_function();

/* int */ calling_function()
{
    long test1;
    register /* int */ test2;

    test1 = some_function();
    if (test1 > 0)
          test2 = 0;
    else
          test2 = other_function();
    return test2;
}

$ cc/warning=warning=all/check=all try.c

/* int */ other_function();
..........................^
%CC-W-NOTYPES, Declaration has no type or storage class.
at line number 2 in file DISK8:[CBERRY.TEST]TRY.C;1
$ cc/warning=warning=all/check=all/standard=vaxc try.c
$

No warnings with /standard=vaxc, even with all warnings enabled.  That's why I put "for the compiler mode you are using" in italics above.  Remove the comments around "int" in the code and you'll get a bit further but see other warnings without /standard=vaxc.

[saulmashbaum]

Those who surmised from my posting that I'm a not-too-expert c programmer

maintaining really old code were absolutely right.

The application in question was written about 20 years ago by a team of programmers, and I inherited it and am maintaining it practically all by myself.

Similarly, the suspicion that compiling with /standard=vaxc/nooptimize was covering up a lot of problems is

right on the money.

I did as suggested, threw out the above qualifiers, and added  

 /warn=(verbose,enable=(questcode)). I then compiled hundreds of modules which compiled cleanly

before.

To my surprise (not to that of experts here) the compiler now found all kids of problems - unreachable

code, no return statement in a non-void routine, signed char value assigned to a unsigned char

variable, nested comments, and even the classic c mistake:

if (a = b)

instead of

if (a == b)

!

I'm in the process of cleaning up all the error messages I now got.

When I move the updated modules to production, I should have a more

stable application. I sure have cleaner code.

Thanks to all who replied.

Saul Mashbaum

[Hoff]

Once you get through the "easy stuff" that the C compiler is (now) finding for you, other common run-time triggers for run-time errors includes omitted error-checking, lack of integrated logging, etc.  Here is a list of some of the more common coding errors.   If you haven't already skimmed it, the Programming Concepts manual in the OpenVMS documentation set can be a good read, too.

[GuentherF]

Re-reading the original post I realized that my mind thought we talk about a user logout (process deletion) when it "bombs" out. But it seems this is only an image exit.

Image exits not planned by the code points to an unhandled exception which should eventually print out some messages or show a bad exit status at DCL. What does a "$ SHOW SYMBOL $STATUS" right after the program "bombs" out (using $SET NOON in the DCL procedure)?

Btw. is MEMBER_ALIGNMENT (the default) used?

/Guenther