httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <man...@io.com>
Subject Re: ap_read() and APR_EOF (Was: Re: cvs commit: apache-2.0/src/main http_protocol.c)
Date Tue, 02 Nov 1999 04:04:08 GMT
On Tue, Nov 02, 1999 at 01:53:28PM +1000, Brian Havard wrote:
> On Mon, 1 Nov 1999 14:33:41 -0500, Manoj Kasichainula wrote:
> 
> >It appears that OS/2's APR code uses APR_EOF in ap_read and ap_write,
> >while Unix's does not. 
> 
> It only returns APR_EOF in the case where 0 bytes were read which I feel is
> the correct behaviour. The status code should tell you WHY you got 0 bytes
> back. Returning 'success' when you failed to read any data makes no sense to
> me.

Think of it from this perspective: the error codes should only be
returned when something goes wrong. EOF isn't necessarily an error. I
can see your point, though. And for sockets, we would probably treat
EOF and errors similarly a lot of the time anyway.

> >I'm not a big fan of APR_EOF in these cases because it makes checking
> >for "success" more complicated. 
> 
> What's wrong with (status == APR_SUCCESS) ?
> The way I've done it you can be sure that 
> if status == APR_SUCCESS then nbytes > 0

Well, when I need nbytes > 0, I check for nbytes > 0. Both checks
should compile to equally fast code. 

If we check for EOF more, than the current OS/2 scheme is better. If
we want to check for exceptional conditions more, then the Unix scheme
is better.

In the end, I don't think it really matters. I'm fine either way.
buff.c is written without any clue about APR_EOF, though.

I'll be extra happy if you want to fix everything to follow this
standard. :)

> BTW, I'm only talking about ap_read(). ap_write() never returns APR_EOF, I
> don't know where you got that one.....

Brain hiccup.

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"This letter is clearly the result of too much spinning." -- The Tick

Mime
View raw message