pset5 resize file io fread

Question

Among the recommended reading list for this pset was this page (http://www.cprogramming.com/tutorial/cfileio.html), which indicates that when using fopen specifically for reading or writing in binary, you should add the character 'b' to the mode argument of fopen. So that would be FILE* inptr = fopen(infile, "rb"). But in copy.c, they just use fopen normally, without the binary flag. Is that wrong, or is the binary flag optional, or are we not actually using binary in this pset?

Also, I'm a little confused about fread. When you specify 'size', for example when reading a pixel from the infile, you could say something like 'sizeof(RGBTRIPLE)'. That tells fread to read 3 bytes (in this case) from our infile. Then the first argument of fread is the variable you want to read TO, so in copy.c that's a variable called triple of type RGBTRIPLE. How does it know which variables in the RGBTRIPLE struct to store which bytes? I'm guessing that it's just reading 3 bytes and storing 1 byte in each of the variables in the struct, but doesn't that seem strange that C has no idea if you're writing too far into an array (for example), but has no problem scanning the different variables in a struct and storing only as many bytes in each variable as that variable can hold? What would happen if we tried to write 4 bytes to a variable of type RGBTRIPLE?

Sorry for the lengthy question, but hopefully someone can shed some light on this.

Answer 1

The C tutorial specifies that you should use the "b" modifier when reading binary files. I don't think this is a binary file.

Regarding your second question, it is reading into the temporary buffer "RGBTRIPLE" in the order it is read from the file. It knows what to store where by the order in which the file is read in to the buffer. If you were reading in the color bytes out of order, then you would have to use some pointer magic to put the out-of-order byte in the right part of the buffer block. In this case, we're reading in order though, so our task is a bit easier.

You are correct that you can read more in to the buffer than the buffer has memory allocated to handle, which would likely result in unexpected behavior including segmentation faults.