This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |