MinGW causing problems with sprintf()

This is a discussion on MinGW causing problems with sprintf() within the C Programming forums, part of the General Programming Boards category; So I've got some code and I'm trying to construct a string which contains a path to file that I ...

  1. #1
    Registered User
    Join Date
    Jan 2010
    Posts
    3

    MinGW causing problems with sprintf()

    So I've got some code and I'm trying to construct a string which contains a path to file that I will later open. When I originally wrote the code I was using Cygwin and GCC and it worked great. No issues. But then I moved to MinGW as the needs for my code changed, and now my sprintf() causes seg faults, not sure why.

    I've done some searching on the net and found that apparently MinGW has alternative functions for safer use...? One was snprintf(), which I called (I believe correctly) and it didn't seg fault but it also didn't produce the correct results. Again, not sure why. Does anyone have any insight into why this might not be working or can anyone explain any issues with strings and their associated functions with MinGW?

    Here's my code:


    Code:
    /*Earlier in code*/
    char TPath[50] = "D:\\Projects\\";
    char TName[500];
    char buf[10];
    
    
    strcpy(TName, TPath);
    strcat(TName, "\\traj");
    snprintf(buf, 6, "%0*5d", xRangekm);
    strcat(TName, buf);
    strcat(TName, "km.ppd");

  2. #2
    Registered User
    Join Date
    Jan 2010
    Posts
    3
    That code isn't exactly the same. My original code had the following original sprintf call

    Code:
    sprintf(buf, "%0*5d", xRangekm);

  3. #3
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Why are you using '*'? That means "take field width from next argument" and there is no such argument. Just use %05d and be done with it.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  4. #4
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by sedavidw View Post
    I've done some searching on the net and found that apparently MinGW has alternative functions for safer use...? One was snprintf(), which I called (I believe correctly) and it didn't seg fault but it also didn't produce the correct results. Again, not sure why.
    I don't use minGW, but a lot of people do -- it is very unlikely that sprintf is broken.

    %0*5d is not a valid template, however (the compiler should tell you that). If you mean "pad to five places with 0", use %05d. * is a flag to indicate that the item should be ignored.
    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

  5. #5
    Registered User
    Join Date
    Jun 2005
    Posts
    6,259
    Quote Originally Posted by MK27 View Post
    %0*5d is not a valid template, however (the compiler should tell you that).
    There is no requirement that the compiler "tell you that". The behaviour when format specifiers do not match the supplied arguments is undefined. No compiler diagnostic is required. While it is true that some compilers parse the format string - if it is available at compile time - the standard does not require that they do so.
    Right 98% of the time, and don't care about the other 3%.

  6. #6
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by grumpy View Post
    There is no requirement that the compiler "tell you that". The behaviour when format specifiers do not match the supplied arguments is undefined. No compiler diagnostic is required. While it is true that some compilers parse the format string - if it is available at compile time - the standard does not require that they do so.
    Compilers which don't do it when possible, are either ancient or stupid.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  7. #7
    Registered User
    Join Date
    Jun 2005
    Posts
    6,259
    Quote Originally Posted by brewbuck View Post
    Compilers which don't do it when possible, are either ancient or stupid.
    Maybe so, but they exist and continued to be used - for both good and bad reasons. That's the real world.

    In any event, even if a compiler can diagnose an invalid format string, the onus is still on the programmer to change it to something valid for the application. Compilers can't do that. The real problem is the need for programmers to access and understand appropriate reference materials so they can do so.
    Right 98% of the time, and don't care about the other 3%.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. No clue how to make a code to solve problems!
    By ctnzn in forum C Programming
    Replies: 8
    Last Post: 10-16-2008, 02:59 AM
  2. strlen causing my program to freeze
    By Beowolf in forum C Programming
    Replies: 2
    Last Post: 09-11-2007, 04:09 PM
  3. C Pointers Problems
    By mhelal in forum C Programming
    Replies: 8
    Last Post: 01-10-2007, 05:35 AM
  4. String Manipulation problems -_-
    By Astra in forum C Programming
    Replies: 5
    Last Post: 12-13-2006, 04:48 PM
  5. DJGPP problems
    By stormswift in forum C Programming
    Replies: 2
    Last Post: 02-26-2002, 03:35 PM

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