By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,404 Members | 2,512 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,404 IT Pros & Developers. It's quick & easy.

Different code behaviour in Unix & Windows

P: n/a
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

Apr 18 '06 #1
Share this Question
Share on Google+
41 Replies


P: n/a

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.

Apr 18 '06 #2

P: n/a

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

Apr 18 '06 #3

P: n/a
In article <11**********************@u72g2000cwu.googlegroups .com>,
tech guru <sa****@gmail.com> 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)
Apr 18 '06 #4

P: n/a
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>

Apr 18 '06 #5

P: n/a
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.

Apr 18 '06 #6

P: n/a
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?
Apr 18 '06 #7

P: n/a
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

Apr 18 '06 #8

P: n/a
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

Apr 18 '06 #9

P: n/a
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

Apr 18 '06 #10

P: n/a
Hi Kenneth,

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

Thanks,
Saumi

Apr 18 '06 #11

P: n/a
tech guru wrote:
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.


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

Apr 18 '06 #12

P: n/a
In article <11*********************@e56g2000cwe.googlegroups. com>,
tech guru <sa****@gmail.com> wrote:
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) .
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer
Apr 18 '06 #13

P: n/a
tech guru wrote:
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

Apr 18 '06 #14

P: n/a
"tech guru" <sa****@gmail.com> writes:
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.

--
Keith Thompson (The_Other_Keith) 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.
Apr 18 '06 #15

P: n/a
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

Apr 18 '06 #16

P: n/a

tech guru wrote:
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

Apr 18 '06 #17

P: n/a

Robert Gamble wrote:
tech guru wrote:
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


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

Apr 18 '06 #18

P: n/a
tech guru wrote:

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:Th*************@gmail.com>
Apr 18 '06 #19

P: n/a
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.

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

--
Ian Collins.
Apr 18 '06 #20

P: n/a
Robert Gamble wrote:
tech guru wrote:
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.

The point is that most of us aren't mind readers
I was expecting a solution from the other half! ;) (basically those who
would have encountered and solved similar problems).
and if you don't
provide any useful information about your problem we can't provide a
very useful answer.
I guess main motive behind my post was to find out the POSSIBLE reasons
which could cause the problem (given that the same piece of code runs
fine on Windows).
Your best bet is to reduce the problem to the
smallest *compilable* program that demonstrates the issue
One way to debug, off course, is to reduce it to a smaller program
while another approach could be to put printf() statements. I was just
trying/hoping to avoid this lenghty debugging part.
and post it
along with your question. Make sure you indicate what is wrong and how
it differs from your expectations.

Robert Gamble


Generally, it is not too difficult to fix an issue once the exact
problem is understood.

Apr 18 '06 #21

P: n/a
"tech guru" <sa****@gmail.com> writes:
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?


<http://www.c-faq.com/fp/libm.html>

If you don't have a "#include <math.h>", you don't have declarations
for round() and sqrt(), and the compiler assumes that they're
functions returning int (at least in C90). I'd expect a warning
unless you mask it with a cast. With or without a cast, you're
invoking undefined behavior. Don't do that.

--
Keith Thompson (The_Other_Keith) 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.
Apr 18 '06 #22

P: n/a
tech guru wrote:
Robert Gamble wrote:
tech guru wrote:
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.

The point is that most of us aren't mind readers


I was expecting a solution from the other half! ;) (basically those who
would have encountered and solved similar problems).
and if you don't
provide any useful information about your problem we can't provide a
very useful answer.


I guess main motive behind my post was to find out the POSSIBLE reasons
which could cause the problem (given that the same piece of code runs
fine on Windows).


There are numerous reasons why you might be encountering the problem
you describe. Why would you waste our time and your time asking us to
try to enumerate every possible situation that might fit your vague
description when you could spend a few minutes to reduce your code,
post it here, and get a clear answer.
Your best bet is to reduce the problem to the
smallest *compilable* program that demonstrates the issue


One way to debug, off course, is to reduce it to a smaller program
while another approach could be to put printf() statements. I was just
trying/hoping to avoid this lenghty debugging part.


Debugging comes with the job, if you can't be bothered to at least take
the steps neccessary to help us help you then you are wasting your time
here.

Robert Gamble

Apr 18 '06 #23

P: n/a
Please post compiler versions for both Windows and Linux. And system
architecture e.g. x86/amd etc.

gcc --version will pop the version number for gcc. Not sure what you
are using under Windows.

As a general piece of advice, compile your code with

gcc -Wall -o bla bla.c

and fix every warning properly. That might give you a hint as to what
is broken.

If it still doesn't work, tell us about what problem you're solving,
how is it that it is numeric and you're using longs instead of doubles.
Posting some example code could also help identify the problem.

Robert Gamble wrote:
tech guru wrote:
Robert Gamble wrote:
tech guru wrote:
> 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.

The point is that most of us aren't mind readers


I was expecting a solution from the other half! ;) (basically those who
would have encountered and solved similar problems).
and if you don't
provide any useful information about your problem we can't provide a
very useful answer.


I guess main motive behind my post was to find out the POSSIBLE reasons
which could cause the problem (given that the same piece of code runs
fine on Windows).


There are numerous reasons why you might be encountering the problem
you describe. Why would you waste our time and your time asking us to
try to enumerate every possible situation that might fit your vague
description when you could spend a few minutes to reduce your code,
post it here, and get a clear answer.
Your best bet is to reduce the problem to the
smallest *compilable* program that demonstrates the issue


One way to debug, off course, is to reduce it to a smaller program
while another approach could be to put printf() statements. I was just
trying/hoping to avoid this lenghty debugging part.


Debugging comes with the job, if you can't be bothered to at least take
the steps neccessary to help us help you then you are wasting your time
here.

Robert Gamble


Apr 18 '06 #24

P: n/a

Robert Gamble wrote:
tech guru wrote:
Robert Gamble wrote:
tech guru wrote:
> 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.
The point is that most of us aren't mind readers


I was expecting a solution from the other half! ;) (basically those who
would have encountered and solved similar problems).
and if you don't
provide any useful information about your problem we can't provide a
very useful answer.


I guess main motive behind my post was to find out the POSSIBLE reasons
which could cause the problem (given that the same piece of code runs
fine on Windows).

There are numerous reasons why you might be encountering the problem
you describe. Why would you waste our time and your time asking us to
try to enumerate every possible situation that might fit your vague
description when you could spend a few minutes to reduce your code,
post it here, and get a clear answer.
There isn't any compulsion that everyone who reads a post must reply.
One should rather never reply if s/he doesn't have a clue about the
problem and/or s/he is not able to provide any answer based on the info
provided in the post. If one is willing to help, s/he can always ask
for more info as par her/his theory about the possible reasons (like
stefan.ciob...@gmail.com and many others have done).
Your best bet is to reduce the problem to the
smallest *compilable* program that demonstrates the issue


One way to debug, off course, is to reduce it to a smaller program
while another approach could be to put printf() statements. I was just
trying/hoping to avoid this lenghty debugging part.


Debugging comes with the job, if you can't be bothered to at least take
the steps neccessary to help us help you then you are wasting your time
here.

Robert Gamble


Debugging is always one option I have got. What I am trying here is to
get some QUICK help, so that I would have to spend less time in
debugging.

Apr 18 '06 #25

P: n/a
tech guru wrote:

Debugging is always one option I have got. What I am trying here is to
get some QUICK help, so that I would have to spend less time in
debugging.

Then post an example that exhibits your problem.

The alternative is a bandwidth wasting thread like this one.

--
Ian Collins.
Apr 18 '06 #26

P: n/a
Ian Collins <ia******@hotmail.com> writes:
tech guru wrote:
Debugging is always one option I have got. What I am trying here is to
get some QUICK help, so that I would have to spend less time in
debugging.

Then post an example that exhibits your problem.

The alternative is a bandwidth wasting thread like this one.


There's always a slight possibility that a vague description will ring
a bell in someone's head, if there happens to be someone out there
who's had a very similar problem.

But it's not the way to bet, and I think we've seen that that's not
likely to happen in this case.

--
Keith Thompson (The_Other_Keith) 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.
Apr 18 '06 #27

P: n/a
"tech guru" <sa****@gmail.com> wrote in news:11*********************@e56g2000cwe.googlegro ups.com:

[ Please do not snip attributions ]
Hi Vladimir, ....
The problem is most likely on line 42.

.... What is the logic behind it? :)


http://en.wikipedia.org/wiki/The_Ans...and_Everything

;-)

--
A. Sinan Unur <1u**@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
Apr 19 '06 #28

P: n/a
tech guru wrote:
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


Are you just thick? No one knows what the fuck line 42 is cuz YOU DIDNT POST
YOUR CODE! So how is anyone going to be able to figure out whats wrong?
Example of your posting technique:
Q: "My program crashes. What is wrong with it?"
Answer: "Line 42"
Get it?
Eric

Apr 19 '06 #29

P: n/a
Eric <No***@invalid.com> writes:
tech guru wrote:
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


Are you just thick? No one knows what the f*** line 42 is cuz YOU DIDNT POST
YOUR CODE! So how is anyone going to be able to figure out whats wrong?
Example of your posting technique:
Q: "My program crashes. What is wrong with it?"
Answer: "Line 42"
Get it?
Eric


Eric, please chill out. Several people have already explained the 42
joke, but when "tech guru" wrote the above it's likely he hadn't seen
any of the explanations yet. Someone not familiar with Hitchhiker's
Guide To The Galaxy might not realize that the "line 42" comment is
intended to be a joke.

Your point is valid, but it's already been made here several times,
and YOU DON'T NEED TO SHOUT.

--
Keith Thompson (The_Other_Keith) 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.
Apr 19 '06 #30

P: n/a
Keith Thompson wrote:
Eric <No***@invalid.com> writes:
tech guru wrote:
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


Are you just thick? No one knows what the f*** line 42 is cuz YOU DIDNT
POST YOUR CODE! So how is anyone going to be able to figure out whats
wrong? Example of your posting technique:
Q: "My program crashes. What is wrong with it?"
Answer: "Line 42"
Get it?
Eric


Eric, please chill out. Several people have already explained the 42
joke, but when "tech guru" wrote the above it's likely he hadn't seen
any of the explanations yet. Someone not familiar with Hitchhiker's
Guide To The Galaxy might not realize that the "line 42" comment is
intended to be a joke.

Your point is valid, but it's already been made here several times,
and YOU DON'T NEED TO SHOUT.

as you wish...
Apr 19 '06 #31

P: n/a
tech guru opined:

Robert Gamble wrote:
tech guru wrote:
> Robert Gamble wrote:
> > tech guru wrote:
> > > 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.
> >
>
> > The point is that most of us aren't mind readers
>
> I was expecting a solution from the other half! ;) (basically
> those who would have encountered and solved similar problems).
>
> > and if you don't
> > provide any useful information about your problem we can't
> > provide a very useful answer.
>
> I guess main motive behind my post was to find out the POSSIBLE
> reasons which could cause the problem (given that the same piece
> of code runs fine on Windows).

There are numerous reasons why you might be encountering the problem
you describe. Why would you waste our time and your time asking us
to try to enumerate every possible situation that might fit your
vague description when you could spend a few minutes to reduce your
code, post it here, and get a clear answer.


There isn't any compulsion that everyone who reads a post must reply.
One should rather never reply if s/he doesn't have a clue about the
problem and/or s/he is not able to provide any answer based on the
info provided in the post. If one is willing to help, s/he can always
ask for more info as par her/his theory about the possible reasons
(like stefan.ciob...@gmail.com and many others have done).


As many of us did, but you're stubbornly refusing to provide any really
useful information. Instead you engage in an endless game of "Why
don't you? Yes, but..."

Show us some code that gives you the problem you describe.
> > Your best bet is to reduce the problem to the
> > smallest *compilable* program that demonstrates the issue
>
> One way to debug, off course, is to reduce it to a smaller program
> while another approach could be to put printf() statements. I was
> just trying/hoping to avoid this lenghty debugging part.


Debugging comes with the job, if you can't be bothered to at least
take the steps neccessary to help us help you then you are wasting
your time here.

Robert Gamble


Debugging is always one option I have got. What I am trying here is
to get some QUICK help, so that I would have to spend less time in
debugging.


You're /already/ debugging, and not very efficiently by the looks of it
(complete with dragging along a bunch of strangers who volunteered to
help).

--
Why use Windows, since there is a door?
(By fa****@galileo.rhein-neckar.de, Andre Fachat)

<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>

Apr 19 '06 #32

P: n/a
On 18 Apr 2006 14:59:22 -0700,
st************@gmail.com <st************@gmail.com> wrote
in Msg. <11*********************@i40g2000cwc.googlegroups. com>
gcc -Wall -o bla bla.c


Make that: gcc -W -Wall -ansi -pedantic -O -o bla bla.c

"-W -Wall" catches more than just "-W".
"-ansi -pedantic" makes the thread topical in this group.
"-O" catches uninitialized variables.

robert
Apr 19 '06 #33

P: n/a
On 18 Apr 2006 15:36:21 -0700,
tech guru <sa****@gmail.com> wrote
in Msg. <11**********************@v46g2000cwv.googlegroups .com>
There isn't any compulsion that everyone who reads a post must reply.
One should rather never reply if s/he doesn't have a clue about the
problem and/or s/he is not able to provide any answer based on the info
provided in the post.
Thanks, Mr "tech guru", for teaching us how to behave on Usenet.
Debugging is always one option I have got. What I am trying here is to
get some QUICK help, so that I would have to spend less time in
debugging.


What you get when starting a discussion on Usenet is just that, a
discussion. During which you have the chance to learn much more about
your problem than you probably would have imagined before. If you are
too impatient for that, Usenet is not the place for you.

robert
Apr 19 '06 #34

P: n/a
On Tue, 18 Apr 2006 23:38:15 GMT,
Keith Thompson <ks***@mib.org> wrote
in Msg. <ln************@nuthaus.mib.org>
There's always a slight possibility that a vague description will ring
a bell in someone's head, if there happens to be someone out there
who's had a very similar problem.


I had it when I ported a lot of DOS (Turbo C) stuff to Linux several
years ago. Buggy code doesn't port well.

robert
Apr 19 '06 #35

P: n/a
tech guru wrote:
Also, the (wrong) big numbers are consistently 2147324616 or 2147321288
which is just less than 2^31 (=2147483648).
what were they supposed to be?
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.
At the same time, even if
I do not have math.h and compile using Makefile (with gcc3 only) it
does not complain!


as other posters have suggested bump up your warning levels to detect
non-portable code

gcc -ansi -pedantic -O2 etc.
There is no obvious per se reason why a well written mathematical
program
runs on windows but not on Unix. Earlier you talked about long,
implying it
was an integer program; now you are using round() and sqrt(), so is
this FP
maths?

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

Apr 19 '06 #36

P: n/a
tech guru wrote:
.... snip ...
Debugging is always one option I have got. What I am trying here
is to get some QUICK help, so that I would have to spend less
time in debugging.


And what you are actually doing is persuading more and more
participants to ignore you now and in the future, by refusing to
post a suitable cut-down program. If you won't help, why should
we?

--
I hear the voices. G W Bush, 2006-04-18
Apr 19 '06 #37

P: n/a
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.

--
"Irrationality is the square root of all evil"
-- Douglas Hofstadter

<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>

Apr 19 '06 #38

P: n/a
"Vladimir S. Oka" <no****@btopenworld.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. (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.

But perhaps the OP has gotten the point by now that he needs to do
some debugging.

--
Keith Thompson (The_Other_Keith) 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.
Apr 19 '06 #39

P: n/a
On 18 Apr 2006 15:36:21 -0700, in comp.lang.c , "tech guru"
<sa****@gmail.com> wrote:

Robert Gamble wrote:
tech guru wrote:
> Robert Gamble wrote:
> > tech guru wrote:
> > > Hi Vladimir,
> > > What is the logic behind it? :) Btw, line 42 is a blank line in
>
> > The point is that most of us aren't mind readers
>
> I guess main motive behind my post was to find out the POSSIBLE reasons
There are numerous reasons why you might be encountering the problem


There isn't any compulsion that everyone who reads a post must reply.


"tech guru", a word of advice. Don't start arguing with the regulars
about what you need to give us in order to get help. It will only
annoy the very people you need to contact.

In order for us to help, you need to give us more info, You've been
asked for that. You won't give it. We can't help. Its your move next.
Debugging is always one option I have got. What I am trying here is to
get some QUICK help, so that I would have to spend less time in
debugging.


Nobody is going to help you to be lazy.

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Apr 19 '06 #40

P: n/a
On Wed, 19 Apr 2006 19:43:50 GMT, Keith Thompson <ks***@mib.org> wrote:
"Vladimir S. Oka" <no****@btopenworld.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.die>
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 :)

Apr 19 '06 #41

P: n/a
Giorgos Keramidas <ke******@ceid.upatras.gr> writes:
On Wed, 19 Apr 2006 19:43:50 GMT, Keith Thompson <ks***@mib.org> wrote:
"Vladimir S. Oka" <no****@btopenworld.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.die>
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_Keith) 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.
Apr 19 '06 #42

This discussion thread is closed

Replies have been disabled for this discussion.