HP aC++/C Compiler Incompatibility?

Hello all,

I am currently working on a debugging project. We have a C program that, long story short, takes some financial figures, performs some arithmetic on them, and outputs them into another file.

This program worked perfectly for years. However, after a recent HP Server upgrade to a box running an Itanium(R) processor and a software upgrade to the HP-UX B.11.23 U ia64 operating system, some of the values being printed out were being "pushed" to the right by one place and zeroes added on the left, while the values that were originally at the farthest to the right were being truncated. (i.e. 123456 became 012345)

This only occurs when the C source code is compiled on the new machine (using the HP aC++/C A.05.50 compiler). The old executables (which were compiled previously on the old hardware and software) still work perfectly.

Any ideas you may have will be very helpful. This has stumped us since March.

Thanks!

Well, I can only assume you did something in the code that's undefined according to the standard or some mistake.

Or your code possibly assumed something about the platform that you were compiling for that is untrue of the new server.

Well that's the confusing part...there were no mistakes in the code before, and no changes were made to it. The change in either the compiler or in the hardware or operating system is what I'm thinking caused the problem.

But what's interesting is that the binaries we compiled before still run perfectly, and correctly, on the new hardware - so I'm led to believe the problem lies in the compilation. Though I'm not sure how/why that would change anything.

Are you sure there are no problems with the code?
Remember that just because happens to run, doesn't mean it's right.
There can be factors in the code that relies on knowledge that the types are of a typical length and such.
I doubt very much it's the compiler.

Well, that is an indication that Elysia and/or I are/am correct about our assessment. Your code is most likely making assumptions that are invalid in certain circumstances.

Well, what you're saying is entirely true - I didn't write the code myself, so I don't know what all it assumes. I can tell you that the vast majority of the data types are doubles and chars, though. I was hoping that it would be perhaps an option that needed to be set with the new compiler or something like that, because I really don't want to wade through 40 pages of code I didn't write looking for someone else's mistake...that's never fun.

But still, I have to re-emphasize that I find it very interesting that the executables compiled with the old compiler still run fine on the new hardware. It's just something different with the way the new compiler handles data types, I'm guessing.

Thanks for your thoughts, though!

Find a few printf() statements which produce different results.

Generate short test programs which invoke examples of those printf() statements, with some meaningful data.

Compile with the old and new compilers, and check results.
If you find one which produces different results, post the code here and we'll tell you what's wrong with it.

I'm afraid I can't use printf statements. I mean, I can print out values in the code I'm working, but can't print out corresponding values in the version of the program that works, because it is in executable format and I have no way of recompiling it without introducing whatever these new errors are in the new compiler.

The more and more I run though this code, the more I'm sure there's a compiler incompatibility, the code is consistent and correct.

At least you can add printf()'s in the code and recompile it. Yes, it'll be wrong, but you'll get to see where it goes wrong, thus possibly leading you to a solution. If you can run the old one with a debugger, you can compare the values of variables to what the new one prints out.

I find it hard to believe the code is consistent and correct and the compiler is broken. The compiler came with this system, and you would be having us believe that your vendors gave you a broken compiler. Perhaps that is the case, but I just think it doesn't make sense to throw up your hands and blame the system before you examine yourself thoroughly.

Quote:

---

Originally Posted by ShearWater509

I'm afraid I can't use printf statements. I mean, I can print out values in the code I'm working, but can't print out corresponding values in the version of the program that works, because it is in executable format and I have no way of recompiling it without introducing whatever these new errors are in the new compiler.

The more and more I run though this code, the more I'm sure there's a compiler incompatibility, the code is consistent and correct.

---

Again, the likelihood that valid, correct code produces different output on different compiler, which both conform to ANSI standard is very slim.
Of course the old executable still runs fine, you didn't recompile anything, but that doesn't mean it's due to the compiler or the libraries. Like everyone here said, it's most likely your code doing something that assumes a certain architecture.
Surely there must some way for you to get access to one of the old servers to compile those test programs?

QuantumPete

The question was.
Do you have access to both compilers?

Sorry about that, I didn't mean to set off anyone's nerves, and I apologize if I did. Certainly not intended.

Sadly no, I don't have access to the old compilers. I'm merely an intern at a huge corporation - I'm very small and they don't give me much to work with or very many resources...at all. I'm about ready to tell them I don't know what is wrong with this program...I'm getting very frustrated with it/staring at code for hours at a time...and I have other projects to do, too.

I've dealt with quite a few proprietary UNIX vendors. While there may in fact be some standard-breaking behavior in your code, the vendor should be ensuring complete backward compatibility between releases. Report it as a bug to HP. If possible, provide them with source that demonstrates the issue.

UNIX vendors will usually NOT respond by saying "change your broken code." For the most part they understand that big customers are unwilling to do that, and will work around the issue themselves. Having said that, if you do detect some standard-breaking behavior in your code, try to fix it.

http://www.gimpel.com/
Run lint on the code, and see what it complains about.
Actually, if you've never done this before, it will complain about a great many things.

Before you baulk at the measly price of $240 for a single licence, add up the salaries of all the people involved with "This has stumped us since March.".

For me, the only issue for the breakage is that someone managed to rely on some undefined or implementation defined behaviour of the old compiler. Was it even an ANSI-C compiler?

Without tools such as lint, it's all too easy to wander off the true ANSI path, and just store up a whole bunch of problems for later.

Or perhaps as a separate exercise, you might get GCC installed on the machine as well.
gcc -W -Wall -ansi -pedantic -O2 prog.c
will also spot a large number of suspicious things as well.