You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by David Horowitz <da...@mcgrawsoftware.com> on 2006/10/24 17:59:41 UTC

apr_socket_recvfrom question

Hi folks,

I'm wondering about apr_socket_recvfrom, specifically the "from" parameter.

It is understood that "from" returns the apr_socketaddr_t of the sending
socket upon return. However, I see discrepancies on whether "from" has any
significance as an input parameter.

APR test code indicates the "from" parameter is used as an input-output
parameter, indicating upon input the sockets from which we are willing to
receive data.

However, recvfrom(2) man page makes no mention of "from" as anything other
than an output parameter, and even mentions it can be NULL if you don't care
about the sender's identifying information.

So, my question: is "from" indeed an input-output parameter, or just an
output parameter? Again, I confirm APR test code indicates it's both, but if
recvfrom(2) doesn't treat it as such, than apr_socket_recvfrom() obviously
won't either.

Does anyone have clarity on this subject?

Thank you,

David

Re: apr_socket_recvfrom question

Posted by Joe Orton <jo...@redhat.com>.
On Tue, Oct 24, 2006 at 11:59:41AM -0400, David Horowitz wrote:
> I'm wondering about apr_socket_recvfrom, specifically the "from" parameter.
> 
> It is understood that "from" returns the apr_socketaddr_t of the sending
> socket upon return. However, I see discrepancies on whether "from" has any
> significance as an input parameter.
> 
> APR test code indicates the "from" parameter is used as an input-output
> parameter, indicating upon input the sockets from which we are willing to
> receive data.

The test case is just resetting the port so it can check whether the 
implementation actually changes it.  Yes, the "from" parameter is just 
an "out" parameter, I've updated the header file to reflect this better, 
hopefully.

Regards,

joe

Re: apr_socket_recvfrom question

Posted by Joe Orton <jo...@redhat.com>.
On Tue, Oct 24, 2006 at 12:20:04PM -0400, Norman Tuttle wrote:
> David:
> 
> (Re: apr_socket_recvfrom() function)
> I already pointed out a bug in this function. I have not had any time
> to fix the problem, and my company chose not to use APR for our
> project in the end.
> Perhaps you can apply the bug fix.

The handling of the sockaddr was buggy, I've fixed this: 
http://svn.apache.org/viewvc?view=rev&revision=467600

If you file bugs in bugzilla they have do have a higher chance of not 
being forgotten about!

Regards,

joe

Re: apr_socket_recvfrom question

Posted by Norman Tuttle <nl...@gmail.com>.
David:

(Re: apr_socket_recvfrom() function)
I already pointed out a bug in this function. I have not had any time
to fix the problem, and my company chose not to use APR for our
project in the end.
Perhaps you can apply the bug fix.

See my post in the archive:
http://mail-archives.apache.org/mod_mbox/apr-dev/200608.mbox/%3ce7fa31290608201939t103c0686xb211e4ade2b41e64@mail.gmail.com%3e

A post from Ruben H. in April also pointed up the same problem:
http://mail-archives.apache.org/mod_mbox/apr-dev/200604.mbox/%3c443CE399.2080800@area99.dk%3e

-Norman Tuttle NLTuttle@gmail.com

On 10/24/06, David Horowitz <da...@mcgrawsoftware.com> wrote:
> Hi folks,
>
> I'm wondering about apr_socket_recvfrom, specifically the "from" parameter.
>
> It is understood that "from" returns the apr_socketaddr_t of the sending
> socket upon return. However, I see discrepancies on whether "from" has any
> significance as an input parameter.
>
> APR test code indicates the "from" parameter is used as an input-output
> parameter, indicating upon input the sockets from which we are willing to
> receive data.
>
> However, recvfrom(2) man page makes no mention of "from" as anything other
> than an output parameter, and even mentions it can be NULL if you don't care
> about the sender's identifying information.
>
> So, my question: is "from" indeed an input-output parameter, or just an
> output parameter? Again, I confirm APR test code indicates it's both, but if
> recvfrom(2) doesn't treat it as such, than apr_socket_recvfrom() obviously
> won't either.
>
> Does anyone have clarity on this subject?
>
> Thank you,
>
> David
>
>
>
>
>