develooper Front page | perl.perl5.porters | Postings from September 2014

Re: [perl #122657] t/io/socket.t failing on hurd: peer from recv()should be empty or the remote name

Thread Previous | Thread Next
From:
Leon Timmermans
Date:
September 26, 2014 18:13
Subject:
Re: [perl #122657] t/io/socket.t failing on hurd: peer from recv()should be empty or the remote name
Message ID:
CAHhgV8hdqrPOhXOJs74cHFyD5eoDccqRvv7a8JArgWKOb3JHRg@mail.gmail.com
On Fri, Sep 26, 2014 at 7:38 PM, Svante Signell <svante.signell@gmail.com>
wrote:

> On Thu, 2014-09-25 at 09:04 -0700, Leon Timmermans via RT wrote:
> > On Thu, Sep 25, 2014 at 10:51 AM, Svante Signell <
> svante.signell@gmail.com>
> > wrote:
> >
> > > FYI: With your patch the test still fails on GNU/Hurd :(
> > >
> >
> > That is unexpected.
> >
> >
> > > Please: How to add (correct) print statements to see what is returned,
> > > you are the "perl" gurus??
> > >
> >
> > printf "%s\n", unpack "H*", $recv_peer;
> > printf "%s\n", unpack "H*", getpeername $child,
> >
> > That should give a hex-dump, which should give some information on why
> they
> > aren't identical.
>
> 100289c37f0000011f0000001f000000
> 100289c37f000001c091070100000000
>

Actually, I'd be curious about the $bind_addr too, but in the big picture
that shouldn't matter.

The 7f000001 is localhost, 89c3 must be the port number (35267). 1002 must
be the address family. The rest of the data looks like garbage to me. It
seems you're leaking it in the padding of the sockaddr_in. Comparing
addresses isn't well-defined, but I'd argue that comparing sockaddr's for
binary equivalence is a perfectly reasonable way to compare them.

That looks to me like a bug in the Hurd, regardless of how perl should
compare addresses.

Leon

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About