problem with output of the program on different OS

[pereges]

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 ?

 

[pereges]

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 ?

 

[Ian Collins]

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.

 

[pereges]

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.

 

[Nick Keighley]

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

 

[jacob navia]

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.

 

[Bart]

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.

 

[pereges]

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.

 

[pereges]

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

 

[Spiros Bousbouras]

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.

 

[Ian Collins]

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.

 

[pereges]

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.

 

[Spiros Bousbouras]

Spiros Bousbouras said:



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.

 

[Ian Collins]

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



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.

 

[pereges]

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.

 

[pereges]

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.v0], obj->vert[obj->tri.v1], obj->vert[obj->tri.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.

 

[pereges]

object o, *obj;

i missed out

obj = &o;

 

[Ian Collins]

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.v0], obj->vert[obj->tri.v1], obj->vert[obj->tri.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.

 

[Antoninus Twink]

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.

 

[pereges]

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.