fwrite和fread的使用讨论

fwrite和fread的使用讨论

有时我们在阅读其他人的代码时，fwrite和fread的使用方式有两种情况：
情况一：

fwrite(header, 46, 1, fpOutCD)
fread(filename, fnsize, 1, fpZip)

情况二：

fwrite(header, 1, 46, fpOutCD)
fread(filename, 1, fnsize, fpZip)

第一感觉第一种情况效率会更高。因为一次就写完了，而第二种需要写多次，每次只写一个字节。
但很多代码中，都是使用第二种写法。这是为什么？

应该第二种方法更合理一点。首先，开发fwrite和fread的作者，肯定不会傻到每次只写一个字节，写N次 ，从glibc源码中可以直接看出。更重要的是，在第二种写法中可以知道写了/读了多少字节。特别是在读的时候。如果是第一种写法，在读的时候，返回0或者1，不知道真正读了多少字节。
举个例子：

return fread(b,1,n,f);

fread()

size_t fread(void*buffer,size_t size,size_t count,FILE*stream);
1.buffer:  是读取的数据存放的内存的指针，
2.size:   是每次读取的字节数
3.count:  是读取的次数
4.stream:  是要读取的文件的指针
      ps： 是数据读取的流（输入流）
返回值：
成功：是实际读取的元素（并非字节）数目
失败：返回0
ps：如果输入过程中遇到了文件尾或者输出过程中出现了错误，这个数字可能比请求的元素数目要小

fwrite()

size_t fwrite(void*buffer,size_ size,size_t count,FILE*stream)
1.buffer：是一个指向用于保存数据的内存位置的指针
2.size：   是每次读取的字节数
3.count：  是读取的次数
4.stream： 是数据写入的流（目标指针的文件）
返回值：
是实际写入的元素（并非字节）数目
ps：如果输入过程中遇到了文件尾或者输出过程中出现了失误，这个数字可能比请求的元素数目要小

glibc–fwrite源码：

#define fwrite(buf, size, count, fp) _IO_fwrite (buf, size, count, fp)

size_t
_IO_fwrite (const void *buf, size_t size, size_t count, FILE *fp)
{
  size_t request = size * count;
  size_t written = 0;
  CHECK_FILE (fp, 0);
  if (request == 0)
    return 0;
  _IO_acquire_lock (fp);
  if (_IO_vtable_offset (fp) != 0 || _IO_fwide (fp, -1) == -1)
    written = _IO_sputn (fp, (const char *) buf, request);
  _IO_release_lock (fp);
  /* We have written all of the input in case the return value indicates
     this or EOF is returned.  The latter is a special case where we
     simply did not manage to flush the buffer.  But the data is in the
     buffer and therefore written as far as fwrite is concerned.  */
  if (written == request || written == EOF)
    return count;
  else
    return written / size;
}

关于_IO_sputn的调用，可以尝试gdb跟踪一下。

参考资料

https://stackoverflow.com/questions/10564562/fwrite-effect-of-size-and-count-on-performance
glibc fread函数源码剖析：https://blog.csdn.net/u012927281/article/details/51932563
统治世界的缓存 — glibc源码拜读 - printf：https://blog.csdn.net/InsZVA/article/details/54234201
IO_FILE泄露libc：https://n0va-scy.github.io/2019/09/21/IO_FILE/
堆进阶学习之第4大利器——IO_File：https://xz.aliyun.com/t/6468