Ok, but I can't understand how it is useful.
In real case, you don't know what the reply is and it's length: so you malloc a buffer big enough and then you read the input. I suppose that the pointer len tells you the number of bytes read. So how can you use this information? I think that only the return state of apr_socket_recv is important. This is why I have asked these questions. Regards --Marco Il mer, 2004-01-07 alle 17:51, Norman Tuttle ha scritto: > I should also point out that the fact the read will be incomplete is > implied by the fact that len is a pointer which really means it is both an > input/output parameter: apr_socket_read will only get (*len) characters. > > -Norman Tuttle [EMAIL PROTECTED] > > On 7 Jan 2004, Marco Spinetti wrote: > > > Hi Jeff, > > > > thanks very much for your reply. > > > > Sorry but I'm new to apr and when I tried to click on apr-docs link in > > http://apr.apache.org/ I can't find anything. > > > > So I have a small question on you reply. > > > > I can find: > > > > - EOF controlling if the return state of apr_socket_recv is APR_EOF. > > - an error if the return state is != APR_SUCCESS > > > > Is it ok? > > > > The reply of my system is dynamic so I suppose that if apr_socket_recv > > replies APR_EOF all my data has been read. > > > > Is it ok? > > > > > > Thanks and regards > > > > > > --Marco > > > > > > > > Il mer, 2004-01-07 alle 17:05, Jeff Trawick ha scritto: > > > Marco Spinetti wrote: > > > > > > > The problem is that the function apr_socket_recv doesn't read all the > > > > output but only a part of it. This function returns APR_SUCCESS before > > > > all the output is sent. > > > > > > > > Shall I set a particular option? > > > > > > no, just loop calling apr_recv until you hit an error or EOF or you read > > > all you expected > > > > > > we should update the docs to say that it will return partial data... > > > since this is the way the raw network APIs work, it probably didn't seem > > > interesting to we implementors > > > > > > > > > > >
