apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Jen <henry...@ztune.net>
Subject Re: [Patch] - apr_recvfrom on Win32 returns 730022 instead of blocking as expected
Date Tue, 22 Feb 2005 06:57:44 GMT
On Sun, Feb 20, 2005 at 06:24:17AM -0500, Jeff Trawick wrote:
> On Fri, 18 Feb 2005 18:45:39 -0800, Henry Jen <henryjen@ztune.net> wrote:
> 
> > Attached patch fix a bug on Win32, if call apr_recvfrom() when no one
> > write to that addr:port, the call returns 730022(WSAEINVAL) instead of
> > blocking as expected.
> > 
> > The reason is that the from->salen was not initialized properly. The
> > patch fix the problem.
> 
> I'm trying to figure out why that field isn't yet set when you call
> apr_recvfrom().
> 

Hmm, I am using a apr_sockaddr_t from stack without initialize it first.
That's what went wrong. I should have initialized it first.

However, I think to reset the value maybe not a bad idea as that's an
input/output field.

> First you call apr_socket_create(), which calls apr_socket_create_ex().
> apr_socket_create_ex() calls set_socket_vars(*new, family, type, protocol).
> set_socket_vars() calls apr_sockaddr_vars_set(sock->remote_addr, family, 0).
> apr_sockaddr_vars_set() will set addr->salen to sizeof(struct sockaddr_in).
> 

This is not about apr_socket_t, it's apr_sockaddr_t(first parameter) for
calling apr_socket_recvfrom. Unless you are suggesting me to use the
remote_addr from apr_socket_t. If that's the idea, why do we need to
passed in the apr_sockaddr_t in the first place?


> Can you tell me where this breaks in your situation?  (i.e., why
> didn't apr_sockaddr_vars_set() set from->salen to the proper value
> before you called apr_socket_recvfrom()?)
> 

I use an apr_sockaddr_t from stack without initialize it. :-)

> Thanks,
> 

Thank you for looking into it. :-)

Henry

Mime
View raw message