/* kff note: I wonder why apr_read() and apr_write() use a
single argument to say both how much data is desired and how
much actually got read, but apr_full_read() and
apr_full_write() use two separate args? */
write_err = apr_full_write (d, buf, bytes_this_time, &bytes_this_time);
Because you will almost never care about how many bytes were actually
written when you do a full_write. Therefore, the API allows you to specify
NULL for that parameter. That can be quite handy when your "bytes_this_time"
parameter doesn't quite match the type in the prototype: &bytes_this_time
will complain, but a simple bytes_this_time will be accepted as the
"correct" type (possibly with size coercion).
IOW, the fourth parameter in the above call can/should be NULL.
Note that full_write will only return fewer bytes if a *real* problem comes
up (out of disk space, device error, etc). apr_write() could return fewer
bytes just because it felt like it. Typically, apr_write will return them
all, but if you're writing into a pipe/socket then it might only write
enough to fill the output buffer. full_write loops on those types of
conditions, and it also loops on an "interrupted system call."
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:08 2006