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