Different code behaviour in Unix & Windows

[tech guru]

Hi,

I am doing some mathematical analysis on large numbers in C. The same
code runs perfectly in Windows but produces unpredictable results in
Unix (like negative numbers or very very big numbers).

I am using 'long' data type which is sufficient to hold the largest
data in the program. I checked the 'sizeof(long)' in both the OS which
is same (=4).

I need to integrate this program with other modules and run from Unix.
So I can not continue to run it from Windows.

Please let me know if you have any clue on the possible problem.

Thanks,
Saumi

[Vladimir S. Oka]

tech guru wrote:

Hi,

I am doing some mathematical analysis on large numbers in C. The same
code runs perfectly in Windows but produces unpredictable results in
Unix (like negative numbers or very very big numbers).

I am using 'long' data type which is sufficient to hold the largest
data in the program. I checked the 'sizeof(long)' in both the OS which
is same (=4).
Did you check that all intermediate results don't overflow? E.g.:

a = (b * c) / d;

will still blow up in your face if `(b * c)` overflows, even if your
algorithm guarantees that the final result will fit into `a`.
I need to integrate this program with other modules and run from Unix.
So I can not continue to run it from Windows.

Please let me know if you have any clue on the possible problem.

The problem is most likely on line 42.

[David Resnick]

tech guru wrote:

Hi,

I am doing some mathematical analysis on large numbers in C. The same
code runs perfectly in Windows but produces unpredictable results in
Unix (like negative numbers or very very big numbers).

I am using 'long' data type which is sufficient to hold the largest
data in the program. I checked the 'sizeof(long)' in both the OS which
is same (=4).

I need to integrate this program with other modules and run from Unix.
So I can not continue to run it from Windows.

Please let me know if you have any clue on the possible problem.

Thanks,
Saumi

If you want much help here, reducing it to a small program that
demonstrates
the problem would be desirable. Of course, if you did that you'd
hopefully
see the answer yourself.

If that isn't feasable, I'd suggest adding some logging code and
pinpoint
where the programs results differ. Should help localize the problem.

-David

[Walter Roberson]

In article <11************ **********@u72g 2000cwu.googleg roups.com>,
tech guru <sa****@gmail.c om> wrote:

I am doing some mathematical analysis on large numbers in C. The same
code runs perfectly in Windows but produces unpredictable results in
Unix (like negative numbers or very very big numbers).
Do you happen to be using bit shifting to the right? If so then you
could be encountering differences as to what gets put into the top bit
as you do the shift.
I am using 'long' data type which is sufficient to hold the largest
data in the program. I checked the 'sizeof(long)' in both the OS which
is same (=4).

If you do happen to be right-shifting then you should use unsigned long
instead of long: with unsigned, the behaviour of the top bit is
predictable.
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)

[Kenneth Brody]

tech guru wrote:

Hi,

I am doing some mathematical analysis on large numbers in C. The same
code runs perfectly in Windows but produces unpredictable results in
Unix (like negative numbers or very very big numbers).

I am using 'long' data type which is sufficient to hold the largest
data in the program. I checked the 'sizeof(long)' in both the OS which
is same (=4).

I need to integrate this program with other modules and run from Unix.
So I can not continue to run it from Windows.

Please let me know if you have any clue on the possible problem.

There is an error on line 42 in your code.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer .h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

[Patrick]

If this is a program to simply sum up numbers, or get averages, or
something like that, then I wouldn't know what to tell you. I've never
worked in Unix myself (in fact, this is my first post, and I'm very
inexperianced with advanced C) but it could be a problem with either
the binary representation of the numbers (particularly negative
numbers), such as one's compliment, two's compliment, or sign bit; or
even the Endian-ness of the system (whether the first byte in a number
is the "high" byte or the "low" byte). As a disclaimer, I don't know
how that would affect your specific program. The only programs I've
seen that would be affected by these things would be block-encryption
programs. I would recommend checking the macro BIG_ENDIAN. There are
definately people here who could answer your question much better than
I could, but this might be something to look into.

[void * clvrmnky()]

Patrick wrote:

If this is a program to simply sum up numbers, or get averages, or
something like that, then I wouldn't know what to tell you. I've never
worked in Unix myself (in fact, this is my first post, and I'm very
inexperianced with advanced C) but it could be a problem with either
the binary representation of the numbers (particularly negative
numbers), such as one's compliment, two's compliment, or sign bit; or
even the Endian-ness of the system (whether the first byte in a number
is the "high" byte or the "low" byte). As a disclaimer, I don't know
how that would affect your specific program. The only programs I've
seen that would be affected by these things would be block-encryption
programs. I would recommend checking the macro BIG_ENDIAN. There are
definately people here who could answer your question much better than
I could, but this might be something to look into.

Who are you talking to?

[tech guru]

Hi Vladimir,

Did you check that all intermediate results don't overflow? E.g.:

a = (b * c) / d;

will still blow up in your face if `(b * c)` overflows, even if your
algorithm guarantees that the final result will fit into `a`.
In some places, I am doing like a += b. But I think the result would
still be fit into a. Moreover, I am getting wrong result even where I
am just finding minimum & maximum values by comparison.
The problem is most likely on line 42.

What is the logic behind it? :) Btw, line 42 is a blank line in my
program, followed by #define. If I ignore comments/blank lines, line 42
points to the definition of a member in a structure.

Thanks,
Saumi

[tech guru]

Hi David,

I was hoping to get help from somebody who would have faced similar
problem so as to cut my debugging efforts. :)

Thanks,
Saumi

[tech guru]

Hi Walter,

I am not using right shifts here. But I think I can try using 'unsigned
long's as I am only getting positive integral values.

Thanks,
Saumi