Understanding fread() C Function for Binary File Reading

  • Thread starter Thread starter Adyssa
  • Start date Start date
  • Tags Tags
    Function
AI Thread Summary
The discussion centers on the use of the fread function in C for reading binary files. The user initially misunderstands how to correctly use the parameters of fread, leading to unexpected results. The correct call should be fread(record_array, sizeof(record), num_records, myfile), which reads the specified number of records of the given size. The confusion arose from reversing the size and nmemb parameters, resulting in only a single record being read instead of the intended total bytes. Additionally, it is clarified that the return value of fread indicates the number of records read, not the byte count. The conversation highlights the importance of understanding function parameters and return values in programming.
Adyssa
Messages
202
Reaction score
3
I'm reading a binary file with fread, and I'm getting some strange results. This is from the man page:

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

The function fread() reads nmemb elements of data, each size bytes long, from the stream pointed to by stream, storing them at the location given by ptr.


I understand it to read (nmemb * size) bytes from the file and I'm trying to use it like this:

fread(record_array, num_records, sizeof(record), myfile)

and I'm expecting to read (num_records * sizeof(record)) bytes, call it 10 * 50 = 500.

However, when I do this, it only reads sizeof(record) (50) bytes. If I call it like this it works fine (many elements of size 1 byte each):

fread(record_array, 1, (num_records * sizeof(record)), myfile)

so it seems to ignore the 2nd function parameter. Weird? It's not killing me, but I'm not sure why the size_t size variable is redundant?
 
Technology news on Phys.org
You are calling fread with the size and nmemb arguments reversed. Your call should be fread (record_array, sizeof(record), num_records, myfile).

The return value from fread is the number of records that were read, not the number of bytes.
 
Oooh I missed that, thanks. Also, they were reversed /facepalm. =S

It's been a long day! :)
 
Thread 'Is this public key encryption?'
I've tried to intuit public key encryption but never quite managed. But this seems to wrap it up in a bow. This seems to be a very elegant way of transmitting a message publicly that only the sender and receiver can decipher. Is this how PKE works? No, it cant be. In the above case, the requester knows the target's "secret" key - because they have his ID, and therefore knows his birthdate.
Back
Top