You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Havard <br...@kheldar.apana.org.au> on 1999/11/02 04:53:28 UTC
ap_read() and APR_EOF (Was: Re: cvs commit: apache-2.0/src/main http_protocol.c)
On Mon, 1 Nov 1999 14:33:41 -0500, Manoj Kasichainula wrote:
>On Mon, Nov 01, 1999 at 10:50:49AM -0000, bjh@hyperreal.org wrote:
>> In ap_send_fb_length() don't treat APR_EOF as a fatal error.
>
>Hmmm, I was under the impression that we didn't really use APR_EOF in
>many places. The buff stuff I've done assumed that EOF would be
>indicated with a zero length read and APR_SUCCESS.
>
>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.
>One standard should be chosen.
Absolutely, and it should be documented somewhere.
>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
BTW, I'm only talking about ap_read(). ap_write() never returns APR_EOF, I
don't know where you got that one.....
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: ap_read() and APR_EOF (Was: Re: cvs commit: apache-2.0/src/main http_protocol.c)
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Mon, 1 Nov 1999 22:04:08 -0600, Manoj Kasichainula wrote:
>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 was thinking of the return value more as a 'status' code than an error code
but that doesn't seem to be the way people are using it, probably because
there's no easy way to distinguish between fatal and non-fatal status codes.
>> >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. :)
Well, I'd be happy to do so if I thought I was going to get a group consensus
on the idea but I'd guess it would just cause confusion in the future. Y'all
are just too used to the posix way.....
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: ap_read() and APR_EOF (Was: Re: cvs commit: apache-2.0/src/main http_protocol.c)
Posted by Manoj Kasichainula <ma...@io.com>.
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
Re: ap_read() and APR_EOF (Was: Re: cvs commit: apache-2.0/src/main
http_protocol.c)
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> >It appears that OS/2's APR code uses APR_EOF in ap_read and ap_write,
> >while Unix's does not.
The reason Unix doesn't return APR_EOF when it hits the end of the file
while reading, is that APR_EOF was introduced long after ap_read was
written. This is a mistake, that would have been corrected in time.
I think I saw one commit that removed APR_EOF from the OS/2 ap_read
function. I really disagree with this. I would like to see OS/2 put
APR_EOF back in, and I would like to see Unix, Windows, and beos put it
in. This is simply an oversight that was introduced because a lot of the
APR status codes were introduced as they were needed. I could only forsee
so much when designing this.
I like the idea of having APR return error codes, and status codes. The
utlimate status is APR_SUCCESS, everything is great and working. But that
isn't the only status that programmers care about. APR_EOF is an
important bit of information to have, and I would like to see it used.
Just my opinion, but I would like to see this re-visited.
Ryan
>
> 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.
>
>
>
> >One standard should be chosen.
>
> Absolutely, and it should be documented somewhere.
>
>
>
> >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
>
> BTW, I'm only talking about ap_read(). ap_write() never returns APR_EOF, I
> don't know where you got that one.....
>
> --
> ______________________________________________________________________________
> | Brian Havard | "He is not the messiah! |
> | brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
> ------------------------------------------------------------------------------
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.