Strange behaviour of GCC

well...i was using Tiny C compiler, now i have installed Mingw with gcc 3.4.5

i have some program where i process images...and print some info.. program compiled fine...but it did not print anything when i compiled it with gcc! very strange...

take a look at the first line in main function... strange thing is.. when i decided to print this word - "something", then all the other info printed successfully but when i remove the printing of this word...nothing else prints in the program..

why does the gcc behaves like that on my first run? :P

Code:

#define snapd(expr) printf(#expr " = %d\n", expr);

int main (int argc, char *argv[])
{
    printf("something");
    FILE *imsnap = fopen(FILE2, "w");


    FILEHEADER imageheader;
    INFOHEADER imageinfo;
    RGBDATA *picture;

    long i,j;

    picture = LoadBmp(&imageheader, &imageinfo, FILE1);



    DrawText(&imageinfo, picture, "ABC", 100, 100, 255,255,0);


    
    SaveBmp(picture, &imageheader, &imageinfo, FILE3);







//saving the RGB data and its index to the separate text file for information
for (j = 0; j <= imageinfo.bwidth * imageinfo.bheight - 1; j++)
    {
    
      fprintf(imsnap, "%d ", (picture+j)->red);
      fprintf(imsnap, "%d ", (picture+j)->green);
      fprintf(imsnap, "%d\t%d\n", (picture+j)->blue, j);
      

        
    }


/**/
    snapd(imageheader.htype);
    snapd(imageheader.hsize);
    snapd(imageheader.hreserved1);
    snapd(imageheader.hreserved2);
    snapd(imageheader.hoffsetbits);

   snapd(imageinfo.bsize);
   snapd(imageinfo.bwidth);
   snapd(imageinfo.bheight);
   snapd(imageinfo.bplanes);
   snapd(imageinfo.bbitcount);
   snapd(imageinfo.bcompression);
   snapd(imageinfo.bimagesize);
   snapd(imageinfo.bxpermeter);
   snapd(imageinfo.bypermeter);
   snapd(imageinfo.bclrused);
   snapd(imageinfo.bclrimportant);




    free(picture);
    fclose(imsnap);


    return 0;
}

Perhaps post the rest of your code?

oh one more thing i discovered... when i removed fprinf statements from my code, the other printf statements worked ok...strange. Cooloorful i think i should also post a code of standard C library here.

Originally Posted by BlackOps

oh one more thing i discovered... when i removed fprinf statements from my code, the other printf statements worked ok...strange. Cooloorful i think i should also post a code of standard C library here.

So probably what you're saying is that when your fprintf statements cause a segfault, the rest of your program doesn't happen.

Code:

for (j = 0; j <= imageinfo.bwidth * imageinfo.bheight - 1; j++)
    {
    
      fprintf(imsnap, "%d ", (picture+j)->red);
      fprintf(imsnap, "%d ", (picture+j)->green);
      fprintf(imsnap, "%d\t%d\n", (picture+j)->blue, j);
      

        
    }

Hmmmm I am no math genius or counting champion of the world but shouldn't imageinfo.bwidth * (imageinfo.bheight - 1) - 1?

shouldn't imageinfo.bwidth * (imageinfo.bheight - 1) - 1?

No, that part of the original code was fine, but it would probably read easier as:

Code:

int image_pixels =  imageinfo.bwidth * imageinfo.bheight;
for (j = 0; j < image_pixels; j++){
    ...

i was aay few days... well... that kind of thing doesnt happen when i compile with tcc (Tiny C compiler)... so... any ideas (not please about the other code...it works fine)?

Originally Posted by Cooloorful

Perhaps post the rest of your code?

^ he had a good point. I am familiar with quite a few libraries but knowledge of libraries is second to knowledge of the fact that assuming what libraries someone is using is a fatal trap. So humor me and show any additional code which may be causing linker related issues or something.

i was just using stdio and stdlib.

Fair enough, so I assume DrawText() is your function, right? Are you sure your LoadBmp() function is loading the data in correctly? I am thinking tcc is aligning the space you are allocating differently than gcc. You are probably overflowing in both, but in the world of tcc, it doesn't matter since you are overflowing into data that you own.

Cooloorful, i appreciate ur attempts to help but i feel that u are in wrong direction.. LoadBmp and SaveText functions work good... problem is in something else...

>> Cooloorful, i appreciate ur attempts to help but i feel that u are in wrong direction.. LoadBmp and SaveText functions work good... problem is in something else...

I'm willing to bet you're wrong. The rule of thumb is that anytime you suspect there is something wrong with the compiler, 99.999% of the time the culprit turns out to be your own code. GCC has been used by thousands (or maybe even millions?) and as a result most bugs have been worked out at this point. I don't think you can say the same of your own code. So I would recommend posting the entire code so that you can have an objective eye look over it to verify it's correctness.

I spent some time trying to find whatever library you may be using, friend. I am truly wanting to help you. If I knew more about your program I feel I could perhaps spot the area where things are going astray. I say this from experience with these sorts of problems. I say this as someone who has developed using cross compilers and ported product to multiple platforms. Compiler A may complain where Compiler B didn't. Hell Compiler A may produce something that works when Compiler B doesn't. But 100% of the time it has been my code that had an error that was either covered by Compiler A's generous memory boundaries or missed by Compiler A's negligence. Either way, 100% of the problems have always been my code, not the compiler.

Some compilers are more "forgiving" than others. But don't mistake their generosity for being correct.

Originally Posted by Cooloorful

Compiler A may complain where Compiler B didn't. Hell Compiler A may produce something that works when Compiler B doesn't. But 100% of the time it has been my code that had an error that was either covered by Compiler A's generous memory boundaries or missed by Compiler A's negligence. Either way, 100% of the problems have always been my code, not the compiler.

Ditto, it can be a shocking experience eg, if you develop 1000's of lines on just one compiler and everything runs perfect with no errors and then on another machine using a different compiler all these little off-by-one overwrites and stuff show up causing crashes when you presumed your code was perfect. But the little bugs were there in the first place, they just didn't have a negative effect because you got lucky in the memory segmentation. I would bet that it doesn't matter what compiler you use, if it is just *one* this will happen. Think of the number of times you catch little stupid errors per hundred lines of code just because they cause a seg fault. I bet you could add 25% to that, in terms of identical minor mistakes that don't result in a seg fault shearly because of particular details in how your particular compiler arranged things. It is not a priority for a compiler to make sure your overwrites will corrupt something, any more than it is to find them (that's C). Because say 75% of overwrites will cause critical corruption, on a different machine and compiler -- particularly 64 to 32 bit -- the memory arrangement *will* be different with such a large program and so 75% of the 25% will now be fatal. That means another 5% of the total might not show up until you try a third system!

But they were all programming errors.

Ah, so you trust the quality of your code more than the quality of GCC.

If we say it's either your not-shown code or GCC is wrong, you would guess it's GCC?

The fact that it ran fine with tcc doesn't mean anything. There's something called undefined bahaviour http://en.wikipedia.org/wiki/Undefined_behavior.