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.

What was the machine that it was originally compiled on? Was it a 32bit processor? If so, it may be a 32bit --> 64bit issue.

gg

Hey all,

Solved the problem! Thank you all for your insights!

I discovered the heart of the problem yesterday afternoon when I started to realize that the problem was in a calculation that converted a price between different monetary units, like Euros to Dollars or Yen to Euros...stuff like that.

This particular part of the program is calculating what it costs for one plant to sell parts to another plant - which may be in a different country - and the way the program works is by using two factors - a conversion TO USD factor, and a conversion FROM USD factor, because, for some legal reason, all the conversions have to go through US dollars. So it's fairly easy, the calculation looks like this ((Price * To USD factor) * From USD factor). If a currency is only being converted to USD, though, it just sets the 'From USD' factor to 1, so it makes no difference.

I did a printf statement on the 'From USD' factor and found out it was being set at 10! Not 1. I traced the problem back further to where that factor (it's actualy like 1.0000000000000) is loaded into an array - one character per index. The array is of size 17, but only indexes 0-15 were being read in and used! I think what is happenning is that the old compiler set aside memory for arrays when they were declared - but the new compiler actually zeros out the indicies. When I printed the contents of the array, there was an extra zero attached to what was read in...thus giving us our order of magnitude difference in the conversion factor, giving us an order of magnitude difference in the converted price, and skewing the results in our final output.

Shrunk the array down to the proper size for the input - problem solved. It must have been working by luck before.

None of you would happen to know of a compiler option for the HP aC++/C Compiler version A.05.50 that would tell it NOT to zero out arrays, would you?

I doubt it zeros out arrays. I have yet to see a compiler that does that.
Regardless of it it does or not, arrays which are not initialized contains undefined data, which is why you should always initialize it before use.
But if there are elements that aren't used as you say, then they shouldn't be there in the first place.

I believe you're going to have to provide more information. Perhaps a snippet of the code where you found the error?

Of course the arrays were initialized before use. You can't use the space in them unless you do. You can't just say array[4]=7 without defining the array first, which includes initializing it. And trust me, I know what I'm talking about - it zeroes out the array. There's no other possible way an extra zero could have gotten in there. I've watched the index thoroughly throughout the program's run, and the array definitely has one more zero in it than the input file does.

I'm not going to provide code, you may consider this thread closed. The problem has been solved. Thanks.

Quote:

---

Originally Posted by ShearWater509

Of course the arrays were initialized before use. You can't use the space in them unless you do. You can't just say array[4]=7 without defining the array first, which includes initializing it. And trust me, I know what I'm talking about - it zeroes out the array.

---

Um, excuse me?

Code:

---

#include <stdio.h>

int main(void)
{
        int i;
        int array[10];
       
        array[4] = 7;
       
        for(i=0;i<sizeof(array)/sizeof(*array);i++)
        {
                printf("array[%d] = %d\n", i, array[i]);
        }
       
        return 0;
}

---

Output on a Windows XP system compiled with MinGW:

Code:

---

array[0] = 2009288233
array[1] = 10
array[2] = 0
array[3] = 0
array[4] = 7
array[5] = 2293556
array[6] = -1
array[7] = 2293728
array[8] = 2009291924
array[9] = 2009147472

---

Arrays are not initialized by default, most certainly not to 0. If this is what you are speaking about, you are relying on undefined behavior, which we told you about previously.

Initialize your arrays manually. Of special interest, if you set the array to any value upon declaration, it will automatically initialize the other remaining elements of the array to 0. If this is what you are speaking about, then this is part of the language and you should not be able to find a compiler extension to break proper C behavior in this regard. Initialize your arrays properly.

The arrays ARE initialized exactly as you show.

Listen, there's no way for me to prove this to you unless you come here and look at the code, which, frankly, is illegal because it is proprietary software. I was just looking for hints, but ended up not needing them.

The problem is solved, this will be my final post on the matter.

If the array is local, it's "initialized" to random stuff by default as shown above. If the array is global, then all the array elements are initialized to zero by default. That's specified in the language and I doubt there's a compiler flag that will override it.

Quote:

---

Originally Posted by ShearWater509

The arrays ARE initialized exactly as you show.

---

Um, you said they were initialized to 0, and I proved that they are not. What are you even trying to argue? You're obviously wrong, unless, as tabstop points out, you're using global or local static data. Even that doesn't make much sense for your situation since your other compiler would have initialized all of the memory in question to 0 as well.

What is likely is that the first compiler initialized all of the local arrays to 0 as a feature, and whoever was used to that compiler when they wrote code for it got lazy and didn't actually initialize everything properly. Thus, the code is relying on undefined behavior, which resulted in you guys not being able to figure it out for months.

This is a good practical example for why people should write standard code.

Quote:

---

Originally Posted by ShearWater509

unless you come here and look at the code, which, frankly, is illegal because it is proprietary software.

---

It's not illegal to look at proprietary software. Copying is illegal under copyright law, you showing it to me might make you break your non-disclosure agreement, but if I were to walk by your desk and read the code on your screen, neither of us is breaking any laws.

QuantumPete

Quote:

---

Originally Posted by QuantumPete

It's not illegal to look at proprietary software. Copying is illegal under copyright law, you showing it to me might make you break your non-disclosure agreement, but if I were to walk by your desk and read the code on your screen, neither of us is breaking any laws.

QuantumPete

---

You may not be breaking laws, but you may be breaking the non-disclosure agreement, and whilst that may not end up with you or me in prison, the potential damages in a lawsuit to a small or medium size company could be bad indeed.

--
Mats