musl/src/stdio/fopencookie.c, branch master musl - an implementation of the standard library for Linux-based systems minor cleanup in fopencookie 2018年04月18日T18:46:05+00:00 Rich Felker dalias@aerifal.cx 2018年04月18日T18:46:05+00:00 4245a233c147e18a841bc6ccd5aafb65d6bca163 assign entire struct rather than member-at-a-time. don't repeat buffer sizes; always use sizeof to ensure consistency.
assign entire struct rather than member-at-a-time. don't repeat buffer
sizes; always use sizeof to ensure consistency.
implement the fopencookie extension to stdio 2017年12月06日T18:11:48+00:00 William Pitcock nenolod@dereferenced.org 2017年12月05日T21:04:43+00:00 061843340fbf2493bb615e20e66f60c5d1ef0455 notes added by maintainer: this function is a GNU extension. it was chosen over the similar BSD function funopen because the latter depends on fpos_t being an arithmetic type as part of its public API, conflicting with our definition of fpos_t and with the intent that it be an opaque type. it was accepted for inclusion because, despite not being widely used, it is usually very difficult to extricate software using it from the dependency on it. calling pattern for the read and write callbacks is not likely to match glibc or other implementations, but should work with any reasonable callbacks. in particular the read function is never called without at least one byte being needed to satisfy its caller, so that spurious blocking is not introduced. contracts for what callbacks called from inside libc/stdio can do are always complicated, and at some point still need to be specified explicitly. at the very least, the callbacks must return or block indefinitely (they cannot perform nonlocal exits) and they should not make calls to stdio using their own FILE as an argument.
notes added by maintainer:
this function is a GNU extension. it was chosen over the similar BSD
function funopen because the latter depends on fpos_t being an
arithmetic type as part of its public API, conflicting with our
definition of fpos_t and with the intent that it be an opaque type. it
was accepted for inclusion because, despite not being widely used, it
is usually very difficult to extricate software using it from the
dependency on it.
calling pattern for the read and write callbacks is not likely to
match glibc or other implementations, but should work with any
reasonable callbacks. in particular the read function is never called
without at least one byte being needed to satisfy its caller, so that
spurious blocking is not introduced.
contracts for what callbacks called from inside libc/stdio can do are
always complicated, and at some point still need to be specified
explicitly. at the very least, the callbacks must return or block
indefinitely (they cannot perform nonlocal exits) and they should not
make calls to stdio using their own FILE as an argument.

AltStyle によって変換されたページ (->オリジナル) /