problem with output of the program on different OS

Discussion in 'C Programming' started by pereges, May 8, 2008.

  1. pereges

    pereges Guest

    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, May 8, 2008
    #1
    1. Advertising

  2. pereges

    pereges Guest

    On May 8, 1:26 pm, Richard Heathfield <> wrote:
    <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 ?
     
    pereges, May 8, 2008
    #2
    1. Advertising

  3. pereges

    Ian Collins Guest

    pereges wrote:
    > On May 8, 1:26 pm, Richard Heathfield <> wrote:
    > <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.
     
    Ian Collins, May 8, 2008
    #3
  4. pereges

    pereges Guest

    On May 8, 1:42 pm, Ian Collins <> wrote:

    > > 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.
     
    pereges, May 8, 2008
    #4
  5. On 8 May, 09:20, pereges <> wrote:
    > 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
     
    Nick Keighley, May 8, 2008
    #5
  6. pereges

    jacob navia Guest

    pereges wrote:
    > On May 8, 1:26 pm, Richard Heathfield <> wrote:
    > <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
     
    jacob navia, May 8, 2008
    #6
  7. pereges

    Bart Guest

    On May 8, 9:20 am, pereges <> wrote:
    > 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
     
    Bart, May 8, 2008
    #7
  8. pereges

    pereges Guest

    On May 8, 6:45 pm, Bart <> wrote:

    > 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, May 9, 2008
    #8
  9. pereges

    pereges Guest

    On May 9, 10:52 am, Richard Heathfield <> wrote:

    > 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
     
    pereges, May 9, 2008
    #9
  10. On 9 May, 07:20, pereges <> wrote:
    > On May 9, 10:52 am, Richard Heathfield <> wrote:
    >
    > > 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.
     
    Spiros Bousbouras, May 9, 2008
    #10
  11. pereges

    Ian Collins Guest

    pereges wrote:
    > On May 9, 10:52 am, Richard Heathfield <> wrote:
    >
    >> 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.
     
    Ian Collins, May 9, 2008
    #11
  12. pereges

    pereges Guest

    On May 9, 12:59 pm, Ian Collins <> wrote:

    > 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.
     
    pereges, May 9, 2008
    #12
  13. On 9 May, 08:51, Richard Heathfield <> wrote:
    > Spiros Bousbouras said:
    >
    > > On 9 May, 07:20, pereges <> wrote:
    > >>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.
     
    Spiros Bousbouras, May 9, 2008
    #13
  14. pereges

    Ian Collins Guest

    pereges wrote:
    > On May 9, 12:59 pm, Ian Collins <> wrote:
    >
    >> 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.
     
    Ian Collins, May 9, 2008
    #14
  15. pereges

    pereges Guest

    On May 9, 1:51 pm, Spiros Bousbouras <> wrote:

    > 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, May 9, 2008
    #15
  16. pereges

    pereges Guest

    On May 9, 2:08 pm, Ian Collins <> wrote:

    > 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, May 9, 2008
    #16
  17. pereges

    pereges Guest

    On May 9, 2:16 pm, pereges <> wrote:

    > object o, *obj;



    i missed out

    obj = &o;
     
    pereges, May 9, 2008
    #17
  18. pereges

    Ian Collins Guest

    pereges wrote:
    > On May 9, 2:08 pm, Ian Collins <> wrote:
    >
    >> 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.

    --
    Ian Collins.
     
    Ian Collins, May 9, 2008
    #18
  19. On 9 May 2008 at 8:22, pereges wrote:
    > On May 9, 12:59 pm, Ian Collins <> wrote:
    >> 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.
     
    Antoninus Twink, May 9, 2008
    #19
  20. pereges

    pereges Guest

    On May 9, 2:56 pm, Ian Collins <> wrote:

    > 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.
     
    pereges, May 9, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Puneet
    Replies:
    16
    Views:
    1,159
    Daniel Vallstrom
    Mar 20, 2005
  2. pradeep
    Replies:
    3
    Views:
    843
    cwdjrxyz
    Jun 7, 2007
  3. Smurff
    Replies:
    10
    Views:
    2,521
    Keith Thompson
    Nov 21, 2008
  4. nickname
    Replies:
    7
    Views:
    1,090
    Nobody
    Aug 26, 2009
  5. pradeep
    Replies:
    3
    Views:
    147
    Dr J R Stockton
    Jun 7, 2007
Loading...

Share This Page