The actual function does not require any gtk, so can be included in a non-gtk test program (removing "*widget" from the preliminary arguments):
Code:
#include <stdio_ext.h> //for __fpurge
static void printfile (GtkWidget *widget, char *filename) {
int len=0;
char *line = NULL;
FILE *fst = fopen (filename, "r");
printf ("\n-----%s-----\n", filename);
while (feof(fst) == 0) {
line = getline(&line,&len,fst);
printf ("%s", line);
}
fclose (fst);
__fpurge(stdout);
}
Again, the mystery is an extra line (of garbage) produced when this function is called within gtk, otherwise __fpurge would be unnecessary.
I am not really sure if my method of reading the file (using "while (feof(fst) == 0)") is a normal practice, and in the final iteration of the loop getline must contain an EOF to trip "feof", and the EOF is printed (except the EOF isn't even a space on the console) Here's another interesting element:
- as already mentioned, if using g_print (from gtk.h) instead of printf, the garbage is actually printed instead of being left in the buffer, as if fflush were used in place of __fpurge. Since the g_print call is before the __fpurge call, printing the garbage can then not be avoided.
- if you include feof's return in the printf (ie, printf("%d %s", feof(fst), line)), in a non-gtk test the output would be:
0 data line 1
0 data line 2
0 data line 3
1 - if you do the same in a gtk context, the final "1" does not appear. If you use g_print, you get:
0 data line 1
0 data line 2
0 data line 3
1 garbage written over data line 3
This is not really a big problem -- I was just hoping there would be someone intimately familiar with gtk2 programming who could tell me why this is. Such explanation might help me in solving future gtk riddles, should they arise...