Greg Stein <gstein@lyra.org> writes:
> /* 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.
Thanks, Greg! (I was counting on your reading that comment. :-) )
-K
> 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."
Received on Sat Oct 21 14:36:08 2006