apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: clean up apr_file_read semantics
Date Fri, 04 May 2001 17:06:10 GMT
Greg Stein <gstein@lyra.org> writes:

> Currently, apr_file_io.h states that apr_file_read() can return bytes *and*
> return APR_EOF at the same time. However, all the implementations will
> return APR_EOF only when nbytes == 0.
> 
> I'd like to fix the comment in apr_file_io.h to state that when APR_EOF is
> returned, that nbytes will be zero.

Please do!

> p.s. I believe there is a bug in win32/readwrite.c::apr_file_read(). In the
> buffered case, if rv == APR_EOF, then it breaks out of the loop. If *len is
> found to be zero, then rv is set to 0 (APR_SUCCESS). I don't see how APR_EOF
> could be returned from that function.

Isn't rv set to 0 (yeah, should be APR_SUCCESS) when *len is non-zero?
That is the very line of code which overrides APR_EOF (or some other
error) if we've already read some data.

-- 
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Mime
View raw message