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

problem with output of the program on different OS

P: n/a
I have a C program which I created on Windows machine. I have compiled
and executed the program on windows machine and it gives me the
consistent output every time i run it. for eg.

input a = 2, b =3

lets say a sum operation is to be performed, then:

output: 5

The output is always consistent and correct with regards to input.

I tried to run the program on my linux machine. The program compiles
and executes but I'm getting strange results. For eg. for the problem
of addition above:

input a = 2 b = 3

output: 1

i execute the program again:

input a = 2 b = 3

output: 6

and again:

input a = 2 b= 3

output 0

What is happening ?
Jun 27 '08 #1
Share this Question
Share on Google+
87 Replies


P: n/a
pereges said:
I have a C program which I created on Windows machine. [...]

The output is always consistent and correct with regards to input.

I tried to run the program on my linux machine. The program compiles
and executes but I'm getting strange results. [...]

What is happening ?
Classic case of undefined behaviour. For a more detailed diagnosis, please
provide source code.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jun 27 '08 #2

P: n/a
On May 8, 1:26 pm, Richard Heathfield <r...@see.sig.invalidwrote:
<snip>
Classic case of undefined behaviour. For a more detailed diagnosis, please
provide source code.
The code is 650 lines and it is divided in many modules. I don't mind
posting it but most people will resent it.

Do yout think problems like this one can arise by using non standard
compilers like PellesC ?
Jun 27 '08 #3

P: n/a
pereges wrote:
On May 8, 1:26 pm, Richard Heathfield <r...@see.sig.invalidwrote:
<snip>
>Classic case of undefined behaviour. For a more detailed diagnosis, please
provide source code.

The code is 650 lines and it is divided in many modules. I don't mind
posting it but most people will resent it.

Do yout think problems like this one can arise by using non standard
compilers like PellesC ?
More likely undefined behaviour in the code that relies on the
behaviour of the original compiler.

Try and distill a short example that demonstrates the problem.

--
Ian Collins.
Jun 27 '08 #4

P: n/a
On May 8, 1:42 pm, Ian Collins <ian-n...@hotmail.comwrote:
Do yout think problems like this one can arise by using non standard
compilers like PellesC ?

More likely undefined behaviour in the code that relies on the
behaviour of the original compiler.

Try and distill a short example that demonstrates the problem.

The original compiler I had used was Pelles C (to get a working
output). I will try to post a small version of my code and describe
where I think the problem lies.
Jun 27 '08 #5

P: n/a
pereges said:
On May 8, 1:26 pm, Richard Heathfield <r...@see.sig.invalidwrote:
<snip>
>Classic case of undefined behaviour. For a more detailed diagnosis,
please provide source code.

The code is 650 lines and it is divided in many modules. I don't mind
posting it but most people will resent it.
Zip up all the .c and .h files and any data required for reproducing the
problem, stick it on the Web somewhere, and post a URL. That way, anyone
who wants to look can do so, without inconveniencing anyone who doesn't
want to.

Don't include executable images or object files in the zip file; nobody
will use them anyway, so they'd just be a waste of bandwidth.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jun 27 '08 #6

P: n/a
On 8 May, 09:20, pereges <Brol...@gmail.comwrote:
I have a C program which I created on Windows machine. I have compiled
and executed the program on windows machine and it gives me the
consistent output every time i run it. for eg.

input a = 2, b =3

lets say a sum operation is to be performed, then:

output: 5

The output is always consistent and correct with regards to input.

I tried to run the program on my linux machine. The program compiles
and executes but I'm getting strange results. For eg. for the problem
of addition above:

input a = 2 b = 3

output: 1

i execute the program again:

input a = 2 b = 3

output: 6

and again:

input a = 2 b= 3

output 0

What is happening ?
there is an instance of Undefined Behaviour on line 42

--
Nick Keighley
Jun 27 '08 #7

P: n/a
pereges wrote:
On May 8, 1:26 pm, Richard Heathfield <r...@see.sig.invalidwrote:
<snip>
>Classic case of undefined behaviour. For a more detailed diagnosis, please
provide source code.

The code is 650 lines and it is divided in many modules. I don't mind
posting it but most people will resent it.

Do yout think problems like this one can arise by using non standard
compilers like PellesC ?

Pelles C is a very standard compiler (ansic 89), and it is derived from
lcc, that is very strictly conforming to C 89. Do not blame the compiler
unless you are very sure of your code.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jun 27 '08 #8

P: n/a
On May 8, 9:20*am, pereges <Brol...@gmail.comwrote:
I have a C program which I created on Windows machine. I have compiled
and executed the program on windows machine and it gives me the
consistent output every time i run it. for eg.

input a = 2, b =3

lets say a sum operation is to be performed, then:

output: 5

The output is always consistent and correct with regards to input.

I tried to run the program on my linux machine. The program compiles
and executes but I'm getting strange results. For eg. for the problem
of addition above:

input a = 2 b = 3

output: 1

i execute the program again:

input a = 2 b = 3

output: 6

and again:

input a = 2 b= 3

output 0

What is happening ?
Well, you can forget about the Windows version and just try some
debugging! Your program clearly isn't producing the output you expect.

Or, to save some work, compile with something like gcc with every
possible warning. Perhaps like:

gcc -W -Wall -ansi -pedantic -Wformat-nonliteral -Wcast-align -
Wpointer-arith -Wbad-function-cast -Wmissing-prototypes -Wstrict-
prototypes -Wmissing-declarations -Winline -Wundef -Wnested-externs -
Wcast-qual -Wshadow -Wconversion -Wwrite-strings -ffloat-store -fno-
builtin -O2 -g -pg YOURPROG.c

(with thanks to R. Heathfield).

Then it might give some clues as to what might be wrong. Maybe some
array is too small; just double each one. It might help, or it might
also hide the real error.

650 lines isn't very big, why many modules? Sometimes separating into
modules can introduce more errors. Perhaps try temporarily combining
into one big file.

--
Bartc
Jun 27 '08 #9

P: n/a
On May 8, 6:45 pm, Bart <b...@freeuk.comwrote:
Well, you can forget about the Windows version and just try some
debugging! Your program clearly isn't producing the output you expect.
Can you please tell me about a good debugger ? Is there some
preliminary stuff I should read about debugging in C prior to using a
debugger ?

650 lines isn't very big, why many modules? Sometimes separating into
modules can introduce more errors. Perhaps try temporarily combining
into one big file.
well, I have a total of 9 modules in my program(counting the .c and
the corresponding .h as 1 module).I was told to write the code in
sucha way that the individual modules can be reused in some other
programs.

Jun 27 '08 #10

P: n/a
pereges said:
On May 8, 6:45 pm, Bart <b...@freeuk.comwrote:
>Well, you can forget about the Windows version and just try some
debugging! Your program clearly isn't producing the output you expect.

Can you please tell me about a good debugger ? Is there some
preliminary stuff I should read about debugging in C prior to using a
debugger ?
Debuggers are over-rated by some people, and can be a huge time sink if
used flailingly.
>650 lines isn't very big, why many modules? Sometimes separating into
modules can introduce more errors. Perhaps try temporarily combining
into one big file.

well, I have a total of 9 modules in my program(counting the .c and
the corresponding .h as 1 module).I was told to write the code in
sucha way that the individual modules can be reused in some other
programs.
Yes, I agree with you that the comment about design was misguided. Module
boundaries should be drawn to reflect differences in functionality. The
idea that you have some kind of Procrustean source bed, such that any file
longer than N lines must be split, is silly.

Is that zip file ready yet?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jun 27 '08 #11

P: n/a
On May 9, 10:52 am, Richard Heathfield <r...@see.sig.invalidwrote:
Debuggers are over-rated by some people, and can be a huge time sink if
used flailingly.
Yes, I agree with you that the comment about design was misguided. Module
boundaries should be drawn to reflect differences in functionality. The
idea that you have some kind of Procrustean source bed, such that any file
longer than N lines must be split, is silly.
Is that zip file ready yet?
http://www.savefile.com/files/1547165

Can you please provide some general tips as to how I can improve my
style of coding ?

thanks
Jun 27 '08 #12

P: n/a
pereges said:
On May 9, 10:52 am, Richard Heathfield <r...@see.sig.invalidwrote:
<snip>
>
>Is that zip file ready yet?

http://www.savefile.com/files/1547165
A somewhat cumbersome interface to a somewhat awkward RAR file. Not your
fault, of course - you take the Web space you can get - but I've bundled
up the files as an easily accessible .zip file, which others may find more
convenient:

http://www.cpax.org.uk/scratch/raytrace.zip
Can you please provide some general tips as to how I can improve my
style of coding ?
Yes, but that reply will take some time to write. *This* reply is really
just to facilitate easy access to your code, for the convenience of others
who may want to help you too. I'll get back to you - watch this space.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jun 27 '08 #13

P: n/a
On 9 May, 07:20, pereges <Brol...@gmail.comwrote:
On May 9, 10:52 am, Richard Heathfield <r...@see.sig.invalidwrote:
Debuggers are over-rated by some people, and can be a huge time sink if
used flailingly.
Yes, I agree with you that the comment about design was misguided. Module
boundaries should be drawn to reflect differences in functionality. The
idea that you have some kind of Procrustean source bed, such that any file
longer than N lines must be split, is silly.
Is that zip file ready yet?

http://www.savefile.com/files/1547165
I've been to the page ; I don't see how to download
your file. I tried both Firefox and Lynx.

Jun 27 '08 #14

P: n/a
Spiros Bousbouras said:
On 9 May, 07:20, pereges <Brol...@gmail.comwrote:
>On May 9, 10:52 am, Richard Heathfield <r...@see.sig.invalidwrote:
Debuggers are over-rated by some people, and can be a huge time sink
if used flailingly.
Yes, I agree with you that the comment about design was misguided.
Module boundaries should be drawn to reflect differences in
functionality. The idea that you have some kind of Procrustean source
bed, such that any file longer than N lines must be split, is silly.
Is that zip file ready yet?

http://www.savefile.com/files/1547165

I've been to the page ; I don't see how to download
your file. I tried both Firefox and Lynx.
I struggled too, but managed it in the end. I copied it to my site, from
where you can easily get it:

http://www.cpax.org.uk/scratch/raytrace.zip

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jun 27 '08 #15

P: n/a
pereges wrote:
On May 9, 10:52 am, Richard Heathfield <r...@see.sig.invalidwrote:
>Debuggers are over-rated by some people, and can be a huge time sink if
used flailingly.

>Yes, I agree with you that the comment about design was misguided. Module
boundaries should be drawn to reflect differences in functionality. The
idea that you have some kind of Procrustean source bed, such that any file
longer than N lines must be split, is silly.

>Is that zip file ready yet?

http://www.savefile.com/files/1547165

Can you please provide some general tips as to how I can improve my
style of coding ?
RAR files are very unfriendly for non-windows users!

A couple of points:

You don't state valid ranges for your inputs, or check them.

In find_closest_intersection, uresult and vresult and index can be used
without being assigned, which probably isn't good.

In create_reflected_rarr.efield isn't initialised.

Somewhere you are corrupting the stack.

--
Ian Collins.
Jun 27 '08 #16

P: n/a
On May 9, 12:59 pm, Ian Collins <ian-n...@hotmail.comwrote:
RAR files are very unfriendly for non-windows users!
I applogize, I don't have winZip utility on my machine.

In find_closest_intersection, uresult and vresult and index can be used
without being assigned, which probably isn't good.
I agree but you have to make sure that these values are accessible to
the calling function i.e. raytrace function. Hence I assigned those
values to the res variable.

In create_reflected_rarr.efield isn't initialised.
It has been initialized in raytrace function.
Jun 27 '08 #17

P: n/a
On 9 May, 08:51, Richard Heathfield <r...@see.sig.invalidwrote:
Spiros Bousbouras said:
On 9 May, 07:20, pereges <Brol...@gmail.comwrote:
>http://www.savefile.com/files/1547165
I've been to the page ; I don't see how to download
your file. I tried both Firefox and Lynx.

I struggled too, but managed it in the end. I copied it to my site, from
where you can easily get it:

http://www.cpax.org.uk/scratch/raytrace.zip
To the OP:

In function main() you have
obj = &o;
obj = malloc(sizeof(object));
i = reader(&obj);
if(i == FAILURE)
printf("program failed in reader module\n");

The two successive assignments to obj cannot be
right. Also you don't make sure that the programme
exits in the case of FAILURE.
Jun 27 '08 #18

P: n/a
pereges wrote:
On May 9, 12:59 pm, Ian Collins <ian-n...@hotmail.comwrote:
>RAR files are very unfriendly for non-windows users!

I applogize, I don't have winZip utility on my machine.

>In find_closest_intersection, uresult and vresult and index can be used
without being assigned, which probably isn't good.

I agree but you have to make sure that these values are accessible to
the calling function i.e. raytrace function. Hence I assigned those
values to the res variable.
Yes, but they are uninitialised, so the values in res are garbage when
used. I see one of them is used as an index.

--
Ian Collins.
Jun 27 '08 #19

P: n/a
On May 9, 1:51 pm, Spiros Bousbouras <spi...@gmail.comwrote:
To the OP:

In function main() you have
obj = &o;
obj = malloc(sizeof(object));
i = reader(&obj);
if(i == FAILURE)
printf("program failed in reader module\n");

The two successive assignments to obj cannot be
right. Also you don't make sure that the programme
exits in the case of FAILURE.
Yes I realize that mistake.

It should have been:

object o, *obj;

i = reader(&obj);

if(i == FAILURE)
{
printf("program failed in reader module!\n");
exit(1);
}

I believe there is no need for o = *obj statement either.
Jun 27 '08 #20

P: n/a
On May 9, 2:08 pm, Ian Collins <ian-n...@hotmail.comwrote:
Yes, but they are uninitialised, so the values in res are garbage when
used. I see one of them is used as an index.
Yes, the values in res are garbage when its pointer is passed to the
find_closest_intersection function. But then, the values of the
members in res(t, u, v , tindex) are modified in that function after
intersect_triangle routine is called. The raytrace function is then
having the modified res.

......
if(intersect_triangle(r->origin, r->direction, obj->vert[obj-
>tri[i].v0], obj->vert[obj->tri[i].v1], obj->vert[obj->tri[i].v2],
&res->t, &res->u, &res->v) == TRUE)
.......

^^ The values in res are getting modified here. res->hit is modified
inside the if clause. The res->tindex is modified after the for loop
and it is assigned the value of the variable index.
Jun 27 '08 #21

P: n/a
On May 9, 2:16 pm, pereges <Brol...@gmail.comwrote:
object o, *obj;

i missed out

obj = &o;
Jun 27 '08 #22

P: n/a
pereges wrote:
On May 9, 2:08 pm, Ian Collins <ian-n...@hotmail.comwrote:
>Yes, but they are uninitialised, so the values in res are garbage when
used. I see one of them is used as an index.

Yes, the values in res are garbage when its pointer is passed to the
find_closest_intersection function. But then, the values of the
members in res(t, u, v , tindex) are modified in that function after
intersect_triangle routine is called. The raytrace function is then
having the modified res.

......
if(intersect_triangle(r->origin, r->direction, obj->vert[obj-
>tri[i].v0], obj->vert[obj->tri[i].v1], obj->vert[obj->tri[i].v2],
&res->t, &res->u, &res->v) == TRUE)
.......

^^ The values in res are getting modified here. res->hit is modified
inside the if clause. The res->tindex is modified after the for loop
and it is assigned the value of the variable index.
But not if the inner if is never true.

--
Ian Collins.
Jun 27 '08 #23

P: n/a
On 9 May 2008 at 8:22, pereges wrote:
On May 9, 12:59 pm, Ian Collins <ian-n...@hotmail.comwrote:
>RAR files are very unfriendly for non-windows users!

I applogize, I don't have winZip utility on my machine.
I believe Info-Zip is available as free software for Windows
(http://www.info-zip.org/).

There's a free unrarlib available on Sourceforge for *nix... presumably
someone's made a binary wrapper too if you dig around.

Jun 27 '08 #24

P: n/a
On May 9, 2:56 pm, Ian Collins <ian-n...@hotmail.comwrote:
But not if the inner if is never true.

You can check that by inserting a small printf statement. TThe inner
if is satisfied in quite a few cases.
Jun 27 '08 #25

P: n/a
pereges wrote:
On May 9, 2:56 pm, Ian Collins <ian-n...@hotmail.comwrote:
>But not if the inner if is never true.

You can check that by inserting a small printf statement. TThe inner
if is satisfied in quite a few cases.
But not all.

--
Ian Collins.
Jun 27 '08 #26

P: n/a
On May 9, 3:53 pm, Ian Collins <ian-n...@hotmail.comwrote:
But not all.
Yes, but this is what we want.
That particular function is meant to determine the closest
polygon(triangle in this case) in a mesh that the ray hits. In some
cases the ray won't hit any triangle in the mesh which means that
res.hit will remain false.
Jun 27 '08 #27

P: n/a
One thing I thought of doing is to get rid of static variables all
together. With dynamic variables, you can free the memory as and when
you want.
Jun 27 '08 #28

P: n/a
On May 9, 7:20*am, pereges <Brol...@gmail.comwrote:
On May 9, 10:52 am, Richard Heathfield <r...@see.sig.invalidwrote:
Debuggers are over-rated by some people, and can be a huge time sink if
used flailingly.
Yes, I agree with you that the comment about design was misguided. Module
boundaries should be drawn to reflect differences in functionality. The
idea that you have some kind of Procrustean source bed, such that any file
longer than N lines must be split, is silly.
Is that zip file ready yet?

http://www.savefile.com/files/1547165
Can we test this code at all?

What input should be given?

What output should there be?

--
Bartc

Jun 27 '08 #29

P: n/a
Richard Heathfield <rj*@see.sig.invalidwrites:
pereges said:
>On May 8, 6:45 pm, Bart <b...@freeuk.comwrote:
>>Well, you can forget about the Windows version and just try some
debugging! Your program clearly isn't producing the output you expect.

Can you please tell me about a good debugger ? Is there some
preliminary stuff I should read about debugging in C prior to using a
debugger ?

Debuggers are over-rated by some people, and can be a huge time sink if
used flailingly.
What total and utter nonsense. When one needs a debugger they are
exceptionally useful. This constant downer you put on debuggers is more
down to your own incompetence at using one. I have never, ever had a
case where using one has cost me time or effort. At the very worst case
it can run in the bg and not actually track anything BUT still be able
to give an IMMEDIATE stack trace in the case of an exception of some
kind.
>
>>650 lines isn't very big, why many modules? Sometimes separating into
modules can introduce more errors. Perhaps try temporarily combining
into one big file.

well, I have a total of 9 modules in my program(counting the .c and
the corresponding .h as 1 module).I was told to write the code in
sucha way that the individual modules can be reused in some other
programs.

Yes, I agree with you that the comment about design was misguided. Module
boundaries should be drawn to reflect differences in functionality. The
idea that you have some kind of Procrustean source bed, such that any file
longer than N lines must be split, is silly.

Is that zip file ready yet?
Jun 27 '08 #30

P: n/a
On May 9, 6:46 pm, Bart <b...@freeuk.comwrote:
On May 9, 2:33 pm, pereges <Brol...@gmail.comwrote:
Didn't like this. I used reader(&obj); (reader takes **object).

I'm sorry, you are correct.

OK, but what should the output be?

With inputs of 40000000, 0.0001 and 1100, I got:

Es: 2.979907e-012 Ei: inf RCS: 0.000000e+000

But then, I'm running on Windows and you say the problem is with
Linux..

I will have to check up some scientific literature to determine what
the *exact* and expected output should be. But I can definetely tell
something is wrong because I'm getting the following output on windows
for the same input that you have taken:

Es: 4.431255e-10 Ei: 1.226668e-04 RCS: 4.539517e+01

There is definetely something wrong and its quite likely that these
are all garbage values
Jun 27 '08 #31

P: n/a
pereges <Br*****@gmail.comwrites:
On May 8, 6:45 pm, Bart <b...@freeuk.comwrote:
>Well, you can forget about the Windows version and just try some
debugging! Your program clearly isn't producing the output you expect.

Can you please tell me about a good debugger ? Is there some
preliminary stuff I should read about debugging in C prior to using a
debugger ?
The fantastic tool "valgrind" reports that the printf on line 45 is
done using uninitialised values. That does seem to be the case.

The E_scattered member of radar has only its imaginary part set in the
initialise function. The value is then updated using both parts.

Valgrind reports other problems, but start with that one.

A few remarks...

You are happy to use C99features but you don't use C99's complex
numbers.

You should re-think when you pass pointers and when you pass
structures by copying. For example, reader is passed an object ** but
it always uses only *obj as a value (it never assigns to *obj which is
why one might sometimes use a double pointer). In other cases, the
whole object structure is copied where I'd expect to see a const
object * parameter for reasons of speed.

--
Ben.
Jun 27 '08 #32

P: n/a
On May 9, 3:11*pm, pereges <Brol...@gmail.comwrote:
On May 9, 6:46 pm, Bart <b...@freeuk.comwrote:
On May 9, 2:33 pm, pereges <Brol...@gmail.comwrote:
Didn't like this. I used reader(&obj); (reader takes **object).

I'm sorry, you are correct.
OK, but what should the output be?
With inputs of 40000000, 0.0001 and 1100, I got:
Es: 2.979907e-012 Ei: inf RCS: 0.000000e+000
But then, I'm running on Windows and you say the problem is with
Linux..

I will have to check up some scientific literature to determine what
the *exact* *and expected output should be. But I can definetely tell
something is wrong because I'm getting the following output on windows
for the same input that you have taken:

Es: 4.431255e-10 Ei: 1.226668e-04 RCS: 4.539517e+01

There is definetely something wrong and its quite likely that these
are all garbage values
Yes, you do have a problem. With lccwin, it gave the results I posted.
On gcc, it gave INF,INF and IND. With DMC it crashed, possibily with
pointer dereferencing (but could not pinpoint where; with debug on it
was somewhere in the runtime).

For ease of testing, I combined all modules into a single module, and
hard-coded those 3 inputs. Next (although I don't have time now) would
be output statements to pinpoint that crash, which hopefully is not
unconnected with the main problem.

It doesn't matter now what the exact results should be; get them
consistent first.

--
Bartc
Jun 27 '08 #33

P: n/a
On May 9, 3:11*pm, pereges <Brol...@gmail.comwrote:
On May 9, 6:46 pm, Bart <b...@freeuk.comwrote:
On May 9, 2:33 pm, pereges <Brol...@gmail.comwrote:
Didn't like this. I used reader(&obj); (reader takes **object).

I'm sorry, you are correct.
OK, but what should the output be?
With inputs of 40000000, 0.0001 and 1100, I got:
Es: 2.979907e-012 Ei: inf RCS: 0.000000e+000
But then, I'm running on Windows and you say the problem is with
Linux..

I will have to check up some scientific literature to determine what
the *exact* *and expected output should be. But I can definetely tell
something is wrong because I'm getting the following output on windows
for the same input that you have taken:

Es: 4.431255e-10 Ei: 1.226668e-04 RCS: 4.539517e+01

There is definetely something wrong and its quite likely that these
are all garbage values
Something went amiss with my last post -- it'll turn up half-finished
soon.

Anyway in find_closest_intersection(), index is not set and makes
res.tindex have funny values in raytrace(), causing array bounds
overflow. But setting this to 0 just gave more errors a bit later on.
Whether this is relevant to your main problem, I don't know, but it
should be fixed.

Hope this helps.

--
Bartc
Jun 27 '08 #34

P: n/a
On May 9, 8:45 pm, Bart <b...@freeuk.comwrote:
Anyway in find_closest_intersection(), index is not set and makes
res.tindex have funny values in raytrace(), causing array bounds
overflow. But setting this to 0 just gave more errors a bit later on.
Whether this is relevant to your main problem, I don't know, but it
should be fixed.

Well, index is set to i.
if(res->t < closestdistance)
{

closestdistance = res->t;
uresult = res->u;
vresult = res->v;
index = i;
}
Jun 27 '08 #35

P: n/a
On May 9, 8:45 pm, Bart <b...@freeuk.comwrote:
Anyway in find_closest_intersection(), index is not set and makes
res.tindex have funny values in raytrace(), causing array bounds
overflow. But setting this to 0 just gave more errors a bit later on.
Whether this is relevant to your main problem, I don't know, but it
should be fixed.

btw i just checked up and all the res.tindex values are in between 0
to 1199 which is valid as there are 1200 triangles in the mesh which
you can verify in the sphere.zeus fiel or simply printing the value
o.ntri (number of triangles). The number of vertices is 601
Jun 27 '08 #36

P: n/a
On May 9, 3:11*pm, pereges <Brol...@gmail.comwrote:
On May 9, 6:46 pm, Bart <b...@freeuk.comwrote:
On May 9, 2:33 pm, pereges <Brol...@gmail.comwrote:
Didn't like this. I used reader(&obj); (reader takes **object).

I'm sorry, you are correct.
OK, but what should the output be?
With inputs of 40000000, 0.0001 and 1100, I got:
Es: 2.979907e-012 Ei: inf RCS: 0.000000e+000
But then, I'm running on Windows and you say the problem is with
Linux..

I will have to check up some scientific literature to determine what
the *exact* *and expected output should be. But I can definetely tell
something is wrong because I'm getting the following output on windows
for the same input that you have taken:

Es: 4.431255e-10 Ei: 1.226668e-04 RCS: 4.539517e+01

There is definetely something wrong and its quite likely that these
are all garbage values
[replying to this message as google not showing your other post]

You're right; find_closest...() was a red herring, I was using a too-
small number of rays.

The crash with DMC was the free(&obj)in main() (&obj doesn't point to
allocated storage).

The discrepancies, well look at these two lines in initialize_radar():

real(radar->E_incident) = 0;
imag(radar->E_scattered) = 0;

Initialise also the other halves of .E_incident and .E_scattered.

Now lccwin, gcc and dmc all give the same results.

Whether they are right or not, I've no idea.

--
Bartc
Jun 27 '08 #37

P: n/a
On May 9, 10:26 pm, Bart <b...@freeuk.comwrote:
On May 9, 3:11 pm, pereges <Brol...@gmail.comwrote:
>
Initialise also the other halves of .E_incident and .E_scattered.

Now lccwin, gcc and dmc all give the same results.

Whether they are right or not, I've no idea.
Thank you very much for pointing out this major flaw.

The output that I'm getting is the same as before(don't know why).
keep in mind that the output i posted earlier was for 1100 rays since
you had taken the same input.

Here's my input:

frequency: 40e+7
amplitude of electrical field: 10e-4
numberofrays: 1000

Output:
Es: 7.085529e-11 Ei: 7.957116e-05 RCS: 1.118991e+01

Can you please check the values.
Jun 27 '08 #38

P: n/a
On May 9, 7:28*pm, pereges <Brol...@gmail.comwrote:
On May 9, 10:26 pm, Bart <b...@freeuk.comwrote:
On May 9, 3:11 pm, pereges <Brol...@gmail.comwrote:
Initialise also the other halves of .E_incident and .E_scattered.
Now lccwin, gcc and dmc all give the same results.
Whether they are right or not, I've no idea.

Thank you very much for pointing out this major flaw.

The output that I'm getting is the same as before(don't know why).
keep in mind that the output i posted earlier was for 1100 rays since
you had taken the same input.

Here's my input:

frequency: 40e+7
amplitude of electrical field: 10e-4
numberofrays: 1000

Output:
Es: 7.085529e-11 Ei: 7.957116e-05 RCS: 1.118991e+01

Can you *please check the values.
This is what I get, taken directly off the screen. Run with the exact
same values:

Enter the frequency of the electromagnetic rays to be fired
40e7
Enter the amplitude of electric field
10e-4
Enter the number of electromagnetic rays to be fired
1000
Es: 7.391785e-011 Ei: 1.112194e-004 RCS: 8.351773e+000

(Note the first two figures are 400,000,000 and 0.001, not 40,000,000
and 0.0001 as I'd used earlier.)

Your original problem was I think inconsistency across OSs, possibly
now it's just logical error. And I don't think many here know whether
these numbers are good or not!

--
Bartc
Jun 27 '08 #39

P: n/a
On May 10, 12:09 am, Bart <b...@freeuk.comwrote:
>

This is what I get, taken directly off the screen. Run with the exact
same values:

Enter the frequency of the electromagnetic rays to be fired
40e7
Enter the amplitude of electric field
10e-4
Enter the number of electromagnetic rays to be fired
1000
Es: 7.391785e-011 Ei: 1.112194e-004 RCS: 8.351773e+000

(Note the first two figures are 400,000,000 and 0.001, not 40,000,000
and 0.0001 as I'd used earlier.)

Your original problem was I think inconsistency across OSs, possibly
now it's just logical error. And I don't think many here know whether
these numbers are good or not!
Strange. The values that you are getting are very different from the
ones that Im getting. Another problem I noticed is that I'm getting
the same value I was getting previously (on windows, compiling with
pellesC) even though you had pointed out a major flaw.

Jun 27 '08 #40

P: n/a
On May 9, 8:14*pm, pereges <Brol...@gmail.comwrote:
On May 10, 12:09 am, Bart <b...@freeuk.comwrote:


This is what I get, taken directly off the screen. Run with the exact
same values:
Enter the frequency of the electromagnetic rays to be fired
40e7
Enter the amplitude of electric field
10e-4
Enter the number of electromagnetic rays to be fired
1000
Es: 7.391785e-011 Ei: 1.112194e-004 RCS: 8.351773e+000
(Note the first two figures are 400,000,000 and 0.001, not 40,000,000
and 0.0001 as I'd used earlier.)
Your original problem was I think inconsistency across OSs, possibly
now it's just logical error. And I don't think many here know whether
these numbers are good or not!

Strange. The values that you are getting are very different from the
ones that Im getting. Another problem I noticed is that I'm getting
the same value I was getting previously (on windows, compiling with
pellesC) even though you had pointed out a major flaw.- Hide quoted text -
Out of 4 Windows C compilers:

lccwin32, gcc, dmc all give: 7.39, 1.11, 8.35 (ignoring exponents)

Pelles C gives: 7.08, 7.95, 1.11 same as you.

Time to suspect Pelles C I think! What are the results on linux?

If you can get at least one more compiler that gives my figures, it's
then easy to print out radar.E_scattered say and see where they
diverge.

But it's also possible there's a bug in Pelles C.

--
Bartc
Jun 27 '08 #41

P: n/a
On May 10, 12:43 am, Bart <b...@freeuk.comwrote:
Out of 4 Windows C compilers:

lccwin32, gcc, dmc all give: 7.39, 1.11, 8.35 (ignoring exponents)

Pelles C gives: 7.08, 7.95, 1.11 same as you.

Time to suspect Pelles C I think! What are the results on linux?

Well I can't access the linux machine right now but I will post the
details as soon as i can.

If you can get at least one more compiler that gives my figures, it's
then easy to print out radar.E_scattered say and see where they
diverge.

But it's also possible there's a bug in Pelles C.
god i never thought about that possibility.

I haven't tried out the program with Turbo C ( or TC++) compiler but I
believe it will be difficult to execute the program because dos has
severe memory limitations ?
Jun 27 '08 #42

P: n/a
On May 10, 11:31 am, Richard Heathfield <r...@see.sig.invalidwrote:
I promised a reply to this, and here it is.
Thank you very much for the help. It has given me a lot of insight on
C programming in general.
Okay, so let's look at the code. You should of course read other people's
replies too, because I'm bound to miss something.

I indented the code to my own taste. It had tabs in, and they had to go,
because Usenet hates tabs. Line numbers refer to /my/ version of the code,
which was the result of indenting the original with these settings:
I understand. What text editors do you personally prefer while working
on linux ? What about vi ?On windows machine, I use Qeditor

The first problem I found was that the project wouldn't compile. That
probably means that you are using C99isms - not wrong, but inconvenient
for those few remaining millions that don't have a C99 compiler. To get
your code to compile, I must either disable C90 conformance in my compiler
or hack the code. Since I don't plan on disabling conformance,
code-hackery happened at this end.

Rule 1 is of course to fix the first diagnostic message first. Now, in this
case, the first few messages were:

raytrace.c: In function `find_closest_intersection':
raytrace.c:29: warning: `index' might be used uninitialized in this
function
raytrace.c: In function `raytrace':
raytrace.c:67: warning: unused variable `i'

The first of these looks dire, but it may well be that obj->ntri is always
greater than 0.
Yes obj->ntri >= 0
At this stage, however, I don't know that. And it would
not hurt to initialise index to -1 at this stage. If it remains -1 after
the loop, the original program was clearly assuming that the loop was
always setting this value, and therefore was broken, so I'm going to
assert that it's not -1... in fact, I'm going to assert that it's
non-negative (because it's set to i, which runs from 0 upwards). This
involves adding <assert.hto the include list, and changing

int index, i;

to

int index = -1, i;

and adding

assert(index >= 0);

just after the for-loop and just before res->t = closestdistance;
I think this is not the problem. It is possible that index will be -1
for many rays and its perfectly normal. The index value is just there
to indicate which triangle the ray has hit. It is possible that the
ray does not hit any triangle. I have a member in the intersectresult
data structure called 'hit'. If the ray does not hit any triangle,
then hit will remain FALSE. index will probably contain some garbage
value. But that's irrelevant since in the raytrace function we are
looking for only those cases where res.hit == TRUE.
Second fix to this file: in the raytrace() function, i is unused, so I
removed it.
Do you think its dangerous to have such declarations in bigger
projects ?
Well, I had to dig through three layers of #include before finding an
include for math.h. Not funny. Still, it's there somewhere.
My idea was to have such declarations at one place. Hence, I included
it in common.h.
>
The other stuff? Well, not your fault - you're using valid C99 syntax - but
my compiler doesn't support it so I'm going to rewrite it into a syntax
that is supported by your compiler and mine. I will take the opportunity
to point out some assumptions that your code is making by asserting that
they are true. I've also re-written your malloc in canonical style:

*pointinarray = malloc(*numpoints * sizeof **pointinarray);

In general, for any object pointer p, you can point it at the memory for N
objects of that type by calling malloc like this:

p = malloc(N * sizeof *p);

Note the leading * on the rightmost p.

Plugging in: for N, you want *numpoints, right? So:

p = malloc(*numpoints * sizeof *p);

For p, you want *pointinarray. Watch carefully, counting stars:

*pointinarray = malloc(*numpoints * sizeof **pointinarray);

And that's it. This form survives a type change without modification
(except, of course, a type change to void *).

I am very suspicious about these lines:

for(yi = 0; yi <= numpointsy; ++yi)
{
for(xi = 0; xi <= numpointsx; ++xi)

How SURE are you that those <= are correct? It's very likely that they
should be < rather than <= but you as the code's author will be able to
work out whether this is an error far more quickly than I can.

My revision of your gen_grid_points function (which requires you to add an
include for the <assert.hheader) looks like this:

int gen_grid_points(vector ** pointinarray,
unsigned long int *numpoints,
double xmax,
double xmin,
double ymax,
double ymin,
double zdist)
{
unsigned long int numpointsx;
unsigned long int numpointsy;
unsigned long int i = 0;
double xlength = xmax - xmin;
double ylength = ymax - ymin;
double xsize;
double ysize;
unsigned long int xi, yi;

assert(pointinarray != NULL);

assert(numpoints != NULL);
assert(*numpoints >= 0);

assert(xmax >= xmin);
assert(ymax >= ymin);

numpointsx = sqrt(*numpoints);
numpointsy = sqrt(*numpoints);

assert(numpointsx 1);
assert(numpointsy 1);

xsize = xlength / (numpointsx - 1);
ysize = ylength / (numpointsy - 1);

*numpoints = (numpointsx + 1) * (numpointsy + 1);

*pointinarray = malloc(*numpoints * sizeof **pointinarray);

if(*pointinarray == NULL)
{
perror("malloc has failed");
return FAILURE;
}

/* Generating the points on the grid, points to be used as ray origin */
for(yi = 0; yi <= numpointsy; ++yi)
{
for(xi = 0; xi <= numpointsx; ++xi)
{
(*pointinarray + i)->x = xmin + xi * xsize;
(*pointinarray + i)->y = ymin + yi * ysize;
(*pointinarray + i)->z = zdist;
++i;
}
}

return SUCCESS;

}

I recommend that you plug this version in, and re-test. Do any of the
assertions fail? If so, that may well be your problem.
Yes, there is some problem while compiling radar.c.

The problem is with the assert(*numpoints >= 0) statement on line
number 32 of radar.c as reported by pellesC compiler:

Building radar.obj.
C:\Documents and Settings\abc\Desktop\raytrace\raytrace\radar.c(32) :
warning #2130: Result of unsigned comparison is constant.
C:\Documents and Settings\abc\Desktop\raytrace\raytrace\radar.c(32) :
fatal error: Internal error: 'Access violation' at 0x004083f3.
I tried to comment that line and then compiled and executed the code.
I get the same output as before for the following input:

frequency: 40e+7
amplitude: 10e-4
numberofrays: 1000

The output is:
Es: 7.085529e-11 Ei: 7.957116e-05 RCS: 1.118991e+01

BartC has obtained similar results using the PellesC compiler but he
is getting different result when using dmc, lccwin, gcc on
windows( all the three results using dmc, lccwin, gcc are same though
for the above input). Can you please tell me what result you have
obtained on your linux machine ? Are the results consistent everytime
the program is executed ?
Jun 27 '08 #43

P: n/a
pereges said:
What text editors do you personally prefer while working
on linux ?
vim
What about vi ?
On my machine, 'vi' is an alias for 'vim'.
On windows machine, I use Qeditor
gvim

<snip>
And it would
>not hurt to initialise index to -1 at this stage. If it remains -1 after
the loop, the original program was clearly assuming that the loop was
always setting this value,
<snip>
I think this is not the problem.
Your code has many problems. This may be one of them.
It is possible that index will be -1
for many rays and its perfectly normal. The index value is just there
to indicate which triangle the ray has hit. It is possible that the
ray does not hit any triangle. I have a member in the intersectresult
data structure called 'hit'. If the ray does not hit any triangle,
then hit will remain FALSE. index will probably contain some garbage
value.
In your original code, its value is indeterminate under those
circumstances, and evaluating an indeterminate value means undefined
behaviour. It's almost certainly not causing your problem, but "almost
certainly" != "certainly"! Fix all the bugs, not just the ones that you
think are important. By all means fix the important ones first, but don't
ignore things you know are wrong but guess aren't a problem - your guess
could be wrong.

You asked for hints on coding style, and that's one of them - *always* make
sure that a value is determinate before accessing it.
But that's irrelevant
That's a guess, and it could be a wrong guess.

<snip>
>Second fix to this file: in the raytrace() function, i is unused, so I
removed it.

Do you think its dangerous to have such declarations in bigger
projects ?
No, but I think it's poor style. The less code you have, the less code you
have to read and understand. Removing dead code is good housekeeping, and
will leave you with less clutter to wade through. This makes your life
easier.
>Well, I had to dig through three layers of #include before finding an
include for math.h. Not funny. Still, it's there somewhere.

My idea was to have such declarations at one place. Hence, I included
it in common.h.
That's not a new idea, but whether it's a /good/ idea is a matter of
opinion. Some people, no doubt, will agree with you about this. Maybe even
some experts will agree with you about this. Personally, I'd rather see
the standard headers included in the source where they're needed.
Otherwise, the reader has to either trust that you've remembered to
include them or go looking to make sure. Neither is comfortable.

<snip>
>I recommend that you plug this version in, and re-test. Do any of the
assertions fail? If so, that may well be your problem.

Yes, there is some problem while compiling radar.c.

The problem is with the assert(*numpoints >= 0) statement on line
number 32 of radar.c as reported by pellesC compiler:

Building radar.obj.
C:\Documents and Settings\abc\Desktop\raytrace\raytrace\radar.c(32) :
warning #2130: Result of unsigned comparison is constant.
Oh, it's unsigned long *. I didn't notice that. Fair enough - the assertion
is unnecessary in that case, since *numpoints can't be negative. So /that/
assertion can be removed.
C:\Documents and Settings\abc\Desktop\raytrace\raytrace\radar.c(32) :
fatal error: Internal error: 'Access violation' at 0x004083f3.
Interesting. That suggests that the pointer is NULL or indeterminate. But
it can't be NULL because I inserted a check: assert(numpoints != NULL);

So it must be a bad pointer. Check the calling code.

<snip>
BartC has obtained similar results using the PellesC compiler but he
is getting different result when using dmc, lccwin, gcc on
windows( all the three results using dmc, lccwin, gcc are same though
for the above input). Can you please tell me what result you have
obtained on your linux machine ? Are the results consistent everytime
the program is executed ?
I haven't got as far as executing it yet. When I get some more time, I'll
do some more code clean-up. When eventually I get around to executing it,
I'll post the result here.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jun 27 '08 #44

P: n/a
On May 10, 1:24*pm, Richard Heathfield <r...@see.sig.invalidwrote:
pereges said:
Can you please tell me what result you have
obtained on your linux machine ? Are the results consistent everytime
the program is executed ?

I haven't got as far as executing it yet. When I get some more time, I'll
do some more code clean-up. When eventually I get around to executing it,
I'll post the result here.
Is it some principle of yours that you never execute any code until
every possible warning has been eliminated and it has been styled
entirely to your satisfaction?

Sounds a bit like premature optimisation to me (when you eventually
run it you find you have to change all that beautifully crafted code).

--
Bartc
Jun 27 '08 #45

P: n/a
Bart said:

<snip>
Is it some principle of yours that you never execute any code until
every possible warning has been eliminated
No (because some compilers emit some pretty daft warnings at times) - but
it is certainly my principle that I never execute any code until it has
successfully compiled.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jun 27 '08 #46

P: n/a
Bart wrote, On 10/05/08 17:26:
On May 10, 1:24 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>pereges said:
>>Can you please tell me what result you have
obtained on your linux machine ? Are the results consistent everytime
the program is executed ?
I haven't got as far as executing it yet. When I get some more time, I'll
do some more code clean-up. When eventually I get around to executing it,
I'll post the result here.

Is it some principle of yours that you never execute any code until
every possible warning has been eliminated and it has been styled
entirely to your satisfaction?
In my opinion you should try to get rid of the warnings or justify why
the code should be left with the warning in it before you try and
execute it. In general getting rid of warnings (when done by
understanding the reason behind the warning and fixing the code properly
rather than just changing it without understanding) will remove bugs
faster than running the code and trying to debug it. Well, it ill until
you are good enough to catch those errors almost all of the time before
the compiler!
Sounds a bit like premature optimisation to me (when you eventually
run it you find you have to change all that beautifully crafted code).
My experience is that most of the time the warnings indicate either
incorrect or badly written code (the more inexperience the programmer
the more true this is, and the OP is inexperienced) so if you done
change it to get rid of the warnings you will have to change it to fix
the bugs that the warnings were warning you about.
--
Flash Gordon
Jun 27 '08 #47

P: n/a
Bart wrote:
On May 10, 1:24 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>pereges said:
>>Can you please tell me what result you have
obtained on your linux machine ? Are the results consistent everytime
the program is executed ?
I haven't got as far as executing it yet. When I get some more time, I'll
do some more code clean-up. When eventually I get around to executing it,
I'll post the result here.

Is it some principle of yours that you never execute any code until
every possible warning has been eliminated and it has been styled
entirely to your satisfaction?

Sounds a bit like premature optimisation to me (when you eventually
run it you find you have to change all that beautifully crafted code).
Why would you execute code that the compiler is unhappy with?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Jun 27 '08 #48

P: n/a
On Sun, 11 May 2008 10:04:20 -0400, Joe Wright wrote:
Bart wrote:
>Is it some principle of yours that you never execute any code until
every possible warning has been eliminated and it has been styled
entirely to your satisfaction?

Sounds a bit like premature optimisation to me (when you eventually run
it you find you have to change all that beautifully crafted code).

Why would you execute code that the compiler is unhappy with?
Possibly because the compiler warns about correct and well-written code.
Jun 27 '08 #49

P: n/a
In article <3f**********************************@c58g2000hsc. googlegroups.com>,
Bart <bc@freeuk.comwrote:
>On May 10, 1:24 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>I haven't got as far as executing it yet. When I get some more time, I'll
do some more code clean-up. When eventually I get around to executing it,
I'll post the result here.

Is it some principle of yours that you never execute any code until
every possible warning has been eliminated and it has been styled
entirely to your satisfaction?

Sounds a bit like premature optimisation to me (when you eventually
run it you find you have to change all that beautifully crafted code).
I can't speak for RH, but I never execute code until I have at least
reasonable confidence that it will do something not entirely unlike
what I expect. The sooner you find and fix errors, the easier it is,
and it's hard to catch coding errors much sooner than "before you run
the code" (though design errors can often be caught before you even
start writing the code).

Eliminating compiler warnings and, for many (but far from all)
stylistic preferences, modifying code to conform to those stylistic
preferences is one way (and a rather cost-effective one when done well)
to increase the level of confidence that the code will do something not
entirely unlike what the programmer expects.
dave

--
Dave Vandervies dj3vande at eskimo dot com
Oh I don't know. There's probably some decent land within a mile or so.
(Shame about all that water you have to dive through to reach it.)
--Tanuki in the scary devil monastery
Jun 27 '08 #50

87 Replies

This discussion thread is closed

Replies have been disabled for this discussion.