fread(3)/fwrite(3) don't call read(2)/write(2)

Florian Weimer fweimer@redhat.com
Wed Oct 11 15:33:00 GMT 2017


On 10/11/2017 05:07 PM, Yubin Ruan wrote:
> Hi glibc developers,
> 
> I am looking into some internals of glibc's implementation of
> fread/fwrite, but surprisingly found that fread/fwrite don't invoke
> the "public available" read/write system call interface, while
> instead, invoke some "vtable"-related function handles.

glibc cannot call read/write to implement any ISO C functions because 
ISO C permits the user to define their own functions called read and write.

In addition, the stdio streams can be backed by memory-mapped files, 
open_memstream and fmemopen, and even old libstdc++ from GCC 2.95.  This 
is why the design is so peculiar (particularly the last item is 
cumbersome to support).

> I got very confused with that and am very curious whether fread/fwrite
> will eventually "drill down" to some
> "xxx_internal_read"/"xxx_internal_write" functionns, like this:
> 
>    fwrite(...)
>      -> _IO_sputn(...)
>      -> ...
>      -> xxx_internal_write(...)

Yes, that goes to the xsputn vtable slot.  For POSIX file descriptors, 
this is implemented in libio/fileops.c _IO_new_file_xsputn, which 
eventually calls _IO_new_file_write through various other indirections.

Thanks,
Florian



More information about the Libc-help mailing list