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
