printf and fprintf give different results

Discussion in 'Mac Programming' started by farmerdoug, Feb 6, 2011.

  1. farmerdoug macrumors 6502a

    Joined:
    Sep 16, 2008
    #1
    The printf below prints
    SPY 06/18/09 -2.690002 -2.690002
    SPY 07/09/09 2.089996 -0.600006
    SPY 09/03/09 0.849998 0.249992

    But the fprintf prints just gibberish that it can't be reproduced here. It deletes itself.

    Code:
    char  **totalreturn;
    
     totalreturn = (char **) calloc(100,sizeof(char*));
            for (i = 0; i< 60; i++)
                totalreturn[i] = (char *) calloc(10,sizeof(char));
    
     struct {
        char date[12];
        float tr;
        int up;
        int cnt;
        float vol;
        float ma;
     //   float oldprice;
        } *result;
        result = calloc(1000, sizeof(result));
    
        FILE *output;
        output = fopen("/ABC.txt", "w");       
               
        printf("%s %s %f %f\n",totalreturn[l], result[i].date, net, gain);
         fprintf(output,"%s, %s, %f, %f\n", totalreturn[l], result[i].date, net, gain);
    
    
    
     
  2. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #2
    Works for me:
    Code:
    // file: fpr.c
    
    #include <stdio.h>
    #include <stdlib.h>
    
    int
    main()
    {
    	char  **totalreturn;
    	int i;  // added
    
    	totalreturn = (char **) calloc(100,sizeof(char*));
    	for (i = 0; i< 60; i++)
                totalreturn[i] = (char *) calloc(10,sizeof(char));
    
    	int l = 1;  // added
    	i = 2;  // added; safe
    
    	float net = 3.0f;  // added
    	float gain = 3.0f;  // added
    
    
     struct {
        char date[12];
        float tr;
        int up;
        int cnt;
        float vol;
        float ma;
     //   float oldprice;
        } *result;
        result = calloc(1000, sizeof(result));
    
        FILE *output;
        output = fopen("/ABC.txt", "w");    
    
    
               
        printf("%s %s %f %f\n",totalreturn[l], result[i].date, net, gain);
         fprintf(output,"%s, %s, %f, %f\n", totalreturn[l], result[i].date, net, gain);
    
    	return 0;  // added
    }
    

    Code:
    [B]gcc -std=c99 fpr.c [/B]
    [B]./a.out[/B]
      3.000000 3.000000
    [B]cat /ABC.txt[/B]
    , , 3.000000, 3.000000
    
    Is /ABC.txt open elsewhere?

    Does fopen() return non-null?

    Do you realize that the "w" to fopen() will truncate all existing file contents?
     
  3. farmerdoug thread starter macrumors 6502a

    Joined:
    Sep 16, 2008
    #3
    ABC.txt not open elsewhere. It was created by fopen. Tried only writing the floats. That didn't help.
     
  4. chown33, Feb 6, 2011
    Last edited: Feb 6, 2011

    chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #4
    Use the debugger.
    Set breakpoints.
    Examine variables.

    If you can't see a problem where you're looking, then maybe it's where you're not looking. Seems obvious, but programmer tunnel-vision is a common debugging problem.

    Bracket the area of the problem with debugging statements. If the earliest debugging statement shows correct output, but the original statement shows a problem, then you know the cause is somewhere between the earliest debugging statement and the original statement.

    fopen() then fprintf() literal text (no % formatters) to the file, then fclose() it. Pause the app (or breakpoint it, or exit(0) it). Check the file for correct literal text. Add a single %f format. Repeat.
     
  5. gnasher729 macrumors P6

    gnasher729

    Joined:
    Nov 25, 2005
    #5


    What is "l" in totalreturn[l]?

    Is this the actual code that didn't work?
     
  6. balamw Moderator

    balamw

    Staff Member

    Joined:
    Aug 16, 2005
    Location:
    New England
    #6
    Another debugging possibility. Use sprintf to format the string before you print it. Use the same string (with or without commas) in the calls to printf and fprintf.

    B
     
  7. farmerdoug thread starter macrumors 6502a

    Joined:
    Sep 16, 2008
    #7
    l is an indexing variable. There is more code but nothing relating to the file.
     
  8. balamw Moderator

    balamw

    Staff Member

    Joined:
    Aug 16, 2005
    Location:
    New England
    #8
    Is it possible that something in that other code is taking i our of range between the two calls? I think that is what gnasher was implying.

    Also, does chown33's code work as expected?

    B
     
  9. gnasher729, Feb 7, 2011
    Last edited: Feb 7, 2011

    gnasher729 macrumors P6

    gnasher729

    Joined:
    Nov 25, 2005
    #9
    What are the bets that the problem is in some code that you didn't post? I don't see a definition of l. Undefined variables can have different values in different bits of code.


    A bit hard to see, but while most of the indices were i's (eyes), one was an l (ell).
     
  10. farmerdoug thread starter macrumors 6502a

    Joined:
    Sep 16, 2008
    #10
    The file is corrupted when writing to result. If I comment out all but one of the result[] = statements, the file is not corrupted. With nothing commented out, it is.

    Code:
     struct {
        char date[12];
        float tr;
        int up;
        int cnt;
        float vol;
        float ma;
        } *result;
        result = calloc(1000, sizeof(result));
    //offending code
    while (fscanf(stocks[l],"%s %f %f %f %d %d\n",date, &price[l][i], &ma, &vol[l],&up, &cnt) != EOF)
                            {
                            strcpy(result[i].date, date);
                            result[i].tr = price[l][i];
                            result[i].up = up;
                            result[i].cnt = cnt;
                            result[i].vol = vol[l];
                            result[i++].ma = ma;
                            }
    
    
    
    
     
  11. balamw Moderator

    balamw

    Staff Member

    Joined:
    Aug 16, 2005
    Location:
    New England
    #11
    That's what I get for reading code on the iPhone. :p

    Side note: I hate that about C.

    Code:
    result[i].ma = ma;
    i++;
    
    would be easier to debug.

    I noticed some funny business with scanf the other day when the input didn't match the format string. Could one of your files be corrupted that way?

    B
     
  12. gnasher729 macrumors P6

    gnasher729

    Joined:
    Nov 25, 2005
    #12
    The offending code is in the line exactly above the line that you marked as "offending code". That's why everyone says again and again and again and again that we need the _actual_ code, not the code where you think the bug is.
     
  13. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #13
    Nice catch.
     
  14. mac2x macrumors 65816

    Joined:
    Sep 19, 2009
    #14
    Also you need to free any memory you allocate.
     

Share This Page