macOS printf and fprintf give different results

[farmerdoug]

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.

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);

 

[chown33]

Works for me:

// 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
}

[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?

 

[farmerdoug]

ABC.txt not open elsewhere. It was created by fopen. Tried only writing the floats. That didn't help.

 

[chown33]

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.

 

[gnasher729]

printf("%s %s %f %f\n",totalreturn[l], result.date, net, gain);
fprintf(output,"%s, %s, %f, %f\n", totalreturn[l], result.date, net, gain);


[/code]

What is "l" in totalreturn[l]?

Is this the actual code that didn't work?

 

[balamw]

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

 

[farmerdoug]

l is an indexing variable. There is more code but nothing relating to the file.

 

[balamw]

l is an indexing variable. There is more code but nothing relating to the file.

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

 

[gnasher729]

l is an indexing variable. There is more code but nothing relating to the file.

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.

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.

A bit hard to see, but while most of the indices were i's (eyes), one was an l (ell).

 

[farmerdoug]

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.

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

 

[balamw]

A bit hard to see, but while most of the indices were i's (eyes), one was an l (ell).

That's what I get for reading code on the iPhone.

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.

result[i++].ma = ma;

Side note: I hate that about C.

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

 

[gnasher729]

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.

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

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.

 

[chown33]

The offending code is in the line exactly above the line that you marked as "offending code".

Nice catch.

 

[mac2x]

Also you need to free any memory you allocate.