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]

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]

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]

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.

 

[Kenneth Brody]

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:[email protected]>

 

[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()]

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

 

[tech guru]

Hi Kenneth,

Is there any logic behind the error on line 42? Still I checked my code
but it is fine.

Thanks,
Saumi

 

[Robert Gamble]

Hi Vladimir,


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.

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.

The point is that most of us aren't mind readers and if you don't
provide any useful information about your problem we can't provide a
very useful answer. Your best bet is to reduce the problem to the
smallest *compilable* program that demonstrates the issue and post it
along with your question. Make sure you indicate what is wrong and how
it differs from your expectations.

Robert Gamble

 

[Walter Roberson]

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.

Hmmm, how do you know the answers are wrong? You are probably
printf() information out, right? Perhaps you are using the wrong
format for that. At a guess, you might be using %d when you should
instead be using %ld. The difference would not matter on a system
where sizeof(int) == sizeof(long), but would matter on a system
where sizeof(int) < sizeof(long) .

 

[Robert Gamble]

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

Please preserve context when you respond so everyone knows what you are
talking about. You apparently know how to do this as you did it in
your post just 3 minutes ago but just in case that was a fluke, check
out <http://cfaj.freeshell.org/google/>

Robert Gamble

 

[Keith Thompson]

Is there any logic behind the error on line 42? Still I checked my code
but it is fine.

Please read <http://cfaj.freeshell.org/google/>.

Robert Gamble explained the 42 joke elsethread.

 

[tech guru]

Also, the (wrong) big numbers are consistently 2147324616 or 2147321288
which is just less than 2^31 (=2147483648).

If I compile like 'gcc3 -o objName sourceName.c', it complains about
round() & sqrt() even if math.h is included. At the same time, even if
I do not have math.h and compile using Makefile (with gcc3 only) it
does not complain!

Any idea?

Thanks,
Saumi

 

[David Resnick]

Also, the (wrong) big numbers are consistently 2147324616 or 2147321288
which is just less than 2^31 (=2147483648).

If I compile like 'gcc3 -o objName sourceName.c', it complains about
round() & sqrt() even if math.h is included. At the same time, even if
I do not have math.h and compile using Makefile (with gcc3 only) it
does not complain!

Any idea?

Thanks,
Saumi

http://c-faq.com/fp/libm.html

And try to quote, the "Also" doesn't tell people what the topic was.

-David

 

[tech guru]

Please preserve context when you respond so everyone knows what you are
talking about. You apparently know how to do this as you did it in
your post just 3 minutes ago but just in case that was a fluke, check
out <http://cfaj.freeshell.org/google/>

Robert Gamble

Sorry I did not know about the "Reply" under the "Show Options". I
copied manually for the previous post. Thanks for the link.

 

[Kenneth Brody]

Hi Kenneth,

Is there any logic behind the error on line 42? Still I checked my code
but it is fine.

(See elsewhere for the links on how to properly use Google's broken Usenet
interface to reply.)

Ponder this: How can I know what is 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:[email protected]>

 

[Ian Collins]

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.

You will have to post (working) example code to get a sensible response.