Question

The following line of code writes unsigned int values into a file but the content of the file is not readable.

struct rabin_polynomial
{
    uint64_t start;
    uint16_t length;
    struct rabin_polynomial *next_polynomial;   
};

fprintf(out_file, "%llu,%u",poly->start,poly->length);

If I display the out put of the code instead to the command line screen it is readable.

the file “out_file” is not opened in binary mode.

Here part of the content of the output file:

 -ÍÍÍÍÍÍp\y";^æó r\ ÍÍÍÍ-       ÍÍÍÍÍÍ
Ø∿»Iðr\ ÍÍÍÍ-      wÍÍÍÍÍÍ7OT-OØÚ‚\ ÍÍÍͤ*      L ÍÍÍÍÍÍî›ùçÉç`‚\ ÍÍÍÍð3       ÍÍÍÍÍÍ
Ø∿»I°‚\ ÍÍÍÍðC       ÍÍÍÍÍÍíK¬è‹Ç{ ƒ\ ÍÍÍÍðS      •   ÍÍÍÍÍÍ-Ló3lJ–ÞPƒ\ ÍÍÍÍ…] 

And here is the expected out put:

0,2861 
2861,4096 
6957,3959 
10916,2380 
13296,4096 
17392,4096 

Answer 1

If you’re not getting the textual values you expect, it’s possibly down to the fact that you’re using incorrect format specifiers (I’m assuming you’ve populated the variables you’re trying to print here, though you may want to confirm this).

%llu is explicitly for unsigned long long int which is not necessarily the same width as uint64_t.

In C99, inttypes.h has macros for the format specifiers to be used for the exact-width and -at-least-as-wide-as data types.

For example:

uint64_t xyzzy = 42;
printf ("Number is: %" PRIu64 "\n", xyzzy);

In this case, PRIu64 means the printf format specifier, unsigned decimal output, for a 64-bit exact width variable. There are a wide variety of others for varying output types, plus equivalents for the scanf family as well (starting with SCN).

Section 7.8.1 Macros for format specifiers of C99 lists them in detail.

---

Based on your update where you’re not getting incorrect numbers but are rather getting what could only be described as rubbish, I would say your problems lie elsewhere. Even with corrupt pointers or data, I would not expect fprintf to generate non-numeric data for numeric format strings. It’s certainly possible since it’s undefined behaviour but very unlikely.

You could get that sort of output for strings but that’s not the case here.

In other words, I think you have to look elsewhere in your code for (as an example) memory corruption issues.

One thing you could do to test if the problem lies in the line you think it does, is to change it to:

printf("DEBUG: %llu,%u\n",poly->start,poly->length);
fprintf(out_file, "%llu,%u",poly->start,poly->length);

and see what comes out on the terminal.