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

[Giorgos Keramidas]

On Wed, 19 Apr 2006 19:43:50 GMT, Keith Thompson <ks***@mib.or g> wrote:

"Vladimir S. Oka" <no****@btopenw orld.com> writes:

Nick Keighley opined:

tech guru wrote:
If I compile like 'gcc3 -o objName sourceName.c', it complains about
round() & sqrt() even if math.h is included.

try linking with the math library (see the clc FAQ for more info)

gcc -lm etc.

Alos just how standard in round()? I'm pretty sure its not C89.
It's not in my C89 draft, but it is in N1124, so I suppose it's C99.

round() is standard in C99, but not in C90.

I think we recently had a thread here where someone's compiler (I
think it was gcc) recognized round(), possibly implementing it with
inline code, but the system's <math.h> header didn't declare it.

I remember one about pow() being replaced by GCC at compile time with
the result for some values. Perhaps this is the one you recall too?

The starting message was the one with:

From: Mark Healey <d...@spammer.d ie>
Subject: I can't seem to use pow()
Message-Id: <pa************ *************** *@spammer.die>
(The compiler, headers, and library are all part of the implementation
as far as the standard is concerned, but if they're provided by
different vendors or other entities they can be inconsistent.) Since
no declaration for round() was visible, the compiler had to assume
that it returns int. (And no, casting the result to double is *not* a
fix for the problem; it merely masks the error.)

I have no idea whether that's the problem here, but it's worth
investigating.

The point made above is also valid though :)

[Keith Thompson]

Giorgos Keramidas <ke******@ceid. upatras.gr> writes:

On Wed, 19 Apr 2006 19:43:50 GMT, Keith Thompson <ks***@mib.or g> wrote:

"Vladimir S. Oka" <no****@btopenw orld.com> writes:

Nick Keighley opined:
tech guru wrote:
> If I compile like 'gcc3 -o objName sourceName.c', it complains about
> round() & sqrt() even if math.h is included.

try linking with the math library (see the clc FAQ for more info)

gcc -lm etc.

Alos just how standard in round()? I'm pretty sure its not C89.

It's not in my C89 draft, but it is in N1124, so I suppose it's C99.

round() is standard in C99, but not in C90.

I think we recently had a thread here where someone's compiler (I
think it was gcc) recognized round(), possibly implementing it with
inline code, but the system's <math.h> header didn't declare it.

I remember one about pow() being replaced by GCC at compile time with
the result for some values. Perhaps this is the one you recall too?

The starting message was the one with:

From: Mark Healey <d...@spammer.d ie>
Subject: I can't seem to use pow()
Message-Id: <pa************ *************** *@spammer.die>

No, that wasn't it. The thread I'm thinking of had the subject
"undefined refrence to a function" (the typo should make it easy to
find in Google).

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.