Thread: HP aC++/C Compiler Incompatibility?

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.

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.

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.

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?

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.