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:
Svante Signell
Date:
September 27, 2014 09:25
Subject:
Re: [perl #122657] t/io/socket.t failing on hurd: peer from recv()should be empty or the remote name
Message ID:
1411809894.4530.8.camel@gmail.com
On Fri, 2014-09-26 at 21:14 +0200, Svante Signell wrote:
> On Fri, 2014-09-26 at 11:13 -0700, Leon Timmermans via RT wrote:
> > 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.
> 
> $bind_name: 100289c57f000001ffffffff01000000
> 
> > 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.
> 
> I'll forward this to the Hurd developers. Are you planning to change
> this test, either way?

Hi, below are some comments from Samuel Thibault on IRC:
(12:39:34 AM) youpi: gnu_srs1: 1002 is not only the address family. 10
is sin_len, thus 16, and 02 is the address family, thus AF_INET
(12:40:15 AM) youpi: I don't know how $recv_peer happened to contain so
many bytes, but it's not supposed to contain so many, but just 16, as
advertised by sin_len
(12:40:26 AM) youpi: (but also returned by getpeername)
(12:40:53 AM) youpi: (which is where perl should be fetching the size,
since sin_len is not really portable)
(12:51:26 AM) youpi: gnu_srs1: btw, « I'd argue that comparing
sockaddr's for binary equivalence is a perfectly reasonable way to
compare them. », I don't agree
(12:51:46 AM) youpi: I don't think the standard asserts that padding
bytes due to alignment have any defined value

As seen above you are comparing padding bytes, and that content is not
defined by any standard. You should decode sin_len from getpeername and
then compare only that many bytes as given by it.



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