apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: svn commit: r821524 - in /apr/apr/trunk: CHANGES include/apr_network_io.h libapr.dsp network_io/beos/socketcommon.c network_io/os2/socket_util.c network_io/unix/socket_util.c test/sockchild.c test/testsock.c
Date Thu, 08 Oct 2009 20:08:47 GMT


On 10/08/2009 09:39 PM, Jim Jagielski wrote:
> 
> On Oct 8, 2009, at 3:10 PM, Ruediger Pluem wrote:
> 
>>
>>
>> On 10/06/2009 08:51 PM, Ruediger Pluem wrote:
>>>
>>> On 10/06/2009 10:52 AM, Joe Orton wrote:
>>
>>>
>>>> or something similar?  The API docs should reflect that the return
>>>> value
>>>> is 1-on-success/zero-on-failure (unusual for APR), and that the
>>>> function
>>>> does not block.
>>>
>>> I can invert the return value as well, but in this case shouldn't this
>>> be reflected in the name as well?
>>> So with inverted return value shouldn't it be
>>>
>>> apr_socket_at_read_not_eof
>>>
>>> or do you think I shouldn't return an int at all and return
>>> apr_status_t instead
>>> with APR_SUCCESS if the read side of our end of the socket is eof
>>> (and leaving the name as apr_socket_at_read_eof in this case)?
>>
>> Sorry for being impatient here, but Joe any comment on the above?
>> I would like to fix this.
>>
>> Regards
>>
>> RĂ¼diger
>>
> 
> apr_socket_readable() ?

It is less about the name as such. It is more about whether to return an
int or apr_status_t and what the return value should be in the case that
the peer has closed the socket.


Regards

RĂ¼diger



Mime
View raw message