Given these two blocks of code

fwrite(&x, sizeof(y), n, z);


for (int i = 0; i < n; i++)
    fwrite(&x, sizeof(y), 1, z);

I was actually working on resize when my resized images were not written correctly using a piece of code similar to the first one!

I spent sometime banging my head against the wall until I decided to change the way I wrote to my outfile and using a piece of code similar to the second one! Everything went well since then!

Per the manual page for fwrite()

size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE *stream);

The function fwrite() writes nmemb elements of data, each size bytes long, to the stream pointed to by stream, obtaining them from the location given by ptr.

Is there really a difference between the first and the second pieces of code? If yes, what is it? If no, what could have possibly went wrong?

Edit: Here are the bytes of a doubly resized 3 x 3 bmp using the first and the second ways respectively

BMP 1:

0000036: 00ff00 00ff00 000000 702126 0900d0 72b7d4 000000 ff0000  .........p!&...r........
000004e: ff0000 000070 212609 00d072 b7d400 00ffff ff00ff 000000  .....p!&...r............
0000066: 007021 260900 d072b7 d40000 ffffff 00ff00 000000 702126  .p!&...r.............p!&
000007e: 0900d0 72b7d4 000000 ff0000 ff0000 000070 212609 00d072  ...r.............p!&...r
0000096: b7d400 0000ff 0000ff 000000 007021 260900 d072b7 d40000  .............p!&...r....

BMP 2:

0000036: 00ff00 00ff00 00ff00 00ff00 00ff00 00ff00 000000 ff0000  ........................
000004e: ff0000 ff0000 ff0000 ff0000 ff0000 0000ff 0000ff 00ffff  ........................
0000066: ffffff ff00ff 0000ff 000000 00ff00 00ff00 ffffff ffffff  ........................
000007e: 00ff00 00ff00 000000 ff0000 ff0000 ff0000 ff0000 ff0000  ........................
0000096: ff0000 0000ff 0000ff 0000ff 0000ff 0000ff 0000ff 000000  ........................
  • It looks like the second block writes the same bytes every time, are you sure this is how you used it? It shouldn't work this way. – skreborn Jun 29 '14 at 19:02
  • They should work the same, both of them writing the same byte a couple number of times. Are you sure you didnt make a syntax error in the fwrite statement? Maybe mixing up the arguments? – Anfernee Jun 29 '14 at 19:08
  • @skreborn I am writing the same bytes everytime on purpose! There are other "outer" parts of the solutions that I kept hidden not to reveal a solution to the problem! And of course it worked and passed check50! – Kareem Jun 29 '14 at 19:12
  • @AJPennster I literally replaced the first piece of code with the second piece of code. I updated my question with some outputs of the bytes of the same resized bmp image using both ways. – Kareem Jun 29 '14 at 19:13
  • Hmmm, pm me your code. This looks interesting. For both the first and second usage – Anfernee Jun 29 '14 at 19:17

According to the documentation of fwrite: fwrite(ptr to an array of elements, size of element (bytes) to write, number of elements of size from array to write, FILE to write them to );

Though that isnt exactly what the documentation had, I changed it up to clarify what exactly each argument meant. What the fwrite was practically doing in the first block of code you have, was writing the bytes of size y that followed the address of x linearly. So it would have written the next chunk of data that followed the pointer in ram, and repeat that n times.

To further clarify if confused, if you have an array of 25 integers called 'x' and you want to write them to a file "f" using fwrite, doing :

`fwrite(&x, sizeof(x[0]), 25, f);` 

would be copying the array to the file.

if instead you have an integer called 'y' and you did:

`fwrite(&y, sizeof(y), 25, f);` 

you would be writing y... along with 24 other blocks of data, each having the same amount of bytes as y. At least, that is what would be expected to happen. The code could also result in unidentified behaviour for we don't have control over the bytes that proceed y. A segmentation fault can also occur.

It is important however, that you understand what the function does. I hope this helps!

| improve this answer | |
  • Good guess, Anfernee! :) – Kareem Jun 29 '14 at 23:08
fwrite(&x, y, n, z);

&x, in this case, doesn't have to be a pointer to an array! It can be pointer to a variable that's not member of an array.

It's just that fwrite(), as per the manual page, reads y bytes every n elements. I just miss interpreted that!

So in case of

&x = 0x123;
y = 4
n = 10

It turns out that fwrite() does NOT write the value stored at 0x123 ten times, but instead, it writes the value at 0x123 then the one stored at 0x127, ... the one stored at 0x163.

If &x is a pointer to an array element and y is the size of the array element though, fwrite() will continue writing the elements sequentially as long as n is less than or equal to the size of that array.

If n is larger than the size of the array though, it'll probably write garbage values!

The return value in this case would be n and I could see these garbage values when reading with fread() (assuming that fwrite() wrote them at the first place and fread() is not the one that read these garbage values).

| improve this answer | |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .