Thread: Strange behaviour of GCC

Perhaps post the rest of your code?

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?

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.

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...

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.