Strange behaviour of GCC

This is a discussion on Strange behaviour of GCC within the C Programming forums, part of the General Programming Boards category; well...i was using Tiny C compiler, now i have installed Mingw with gcc 3.4.5 i have some program where i ...

  1. #1
    Registered User BlackOps's Avatar
    Join Date
    Jul 2009
    Location
    AZERBAIJAN
    Posts
    78

    Thumbs down 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;
    }

  2. #2
    Registered User Cooloorful's Avatar
    Join Date
    Feb 2009
    Posts
    59
    Perhaps post the rest of your code?
    wipe on -
    A slap on the hand is better than a slap on the face. A tragic lesson learned far too late in life.
    - wipe off

  3. #3
    Registered User BlackOps's Avatar
    Join Date
    Jul 2009
    Location
    AZERBAIJAN
    Posts
    78
    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.

  4. #4
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    Quote Originally Posted by BlackOps View Post
    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.

  5. #5
    Registered User Cooloorful's Avatar
    Join Date
    Feb 2009
    Posts
    59
    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?
    wipe on -
    A slap on the hand is better than a slap on the face. A tragic lesson learned far too late in life.
    - wipe off

  6. #6
    Dr Dipshi++ mike_g's Avatar
    Join Date
    Oct 2006
    Location
    On me hyperplane
    Posts
    1,218
    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++){
        ...

  7. #7
    Registered User BlackOps's Avatar
    Join Date
    Jul 2009
    Location
    AZERBAIJAN
    Posts
    78
    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)?

  8. #8
    Registered User Cooloorful's Avatar
    Join Date
    Feb 2009
    Posts
    59
    Quote Originally Posted by Cooloorful View Post
    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.
    wipe on -
    A slap on the hand is better than a slap on the face. A tragic lesson learned far too late in life.
    - wipe off

  9. #9
    Registered User BlackOps's Avatar
    Join Date
    Jul 2009
    Location
    AZERBAIJAN
    Posts
    78
    i was just using stdio and stdlib.

  10. #10
    Registered User Cooloorful's Avatar
    Join Date
    Feb 2009
    Posts
    59
    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.
    wipe on -
    A slap on the hand is better than a slap on the face. A tragic lesson learned far too late in life.
    - wipe off

  11. #11
    Registered User BlackOps's Avatar
    Join Date
    Jul 2009
    Location
    AZERBAIJAN
    Posts
    78
    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...

  12. #12
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,600
    >> 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.
    Code:
    if( numeric_limits< byte >::digits != bits_per_byte )
        error( "program requires bits_per_byte-bit bytes" );
    24bbs.cpp

  13. #13
    Registered User Cooloorful's Avatar
    Join Date
    Feb 2009
    Posts
    59
    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.
    wipe on -
    A slap on the hand is better than a slap on the face. A tragic lesson learned far too late in life.
    - wipe off

  14. #14
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Cooloorful View Post
    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.
    Last edited by MK27; 07-29-2009 at 06:46 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  15. #15
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,145
    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.
    Last edited by cyberfish; 07-29-2009 at 06:49 PM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Buidl Library with ./configure script
    By Jardon in forum C Programming
    Replies: 6
    Last Post: 07-24-2009, 09:36 AM
  2. Strange gcc warning messages with derived classes
    By skewray in forum C++ Programming
    Replies: 5
    Last Post: 09-23-2007, 04:46 AM
  3. GCC - Strange networking functions error.
    By maththeorylvr in forum Windows Programming
    Replies: 3
    Last Post: 04-05-2005, 12:00 AM
  4. GetClientRect strange behaviour
    By btq in forum Windows Programming
    Replies: 2
    Last Post: 10-02-2002, 02:13 PM
  5. Strange behaviour
    By PrivatePanic in forum Windows Programming
    Replies: 11
    Last Post: 07-23-2002, 12:54 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21