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 27, 2014 14:01
Subject:
Re: [perl #122657] t/io/socket.t failing on hurd: peer from recv()should be empty or the remote name
Message ID:
CAHhgV8hURrWyhewnUaeBeuOYqRsneUUDKZG=1=Yabud3Ed8kyA@mail.gmail.com
On Sat, Sep 27, 2014 at 11:24 AM, Svante Signell <svante.signell@gmail.com>
wrote:

> 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)
>

$recv_peer is containing exactly 16 bytes (or 32 hex characters). 1 for the
length, 1 for the address family, 2 for the port number, 4 for the IP
address and 8 without apparent function. I assume this is because struct
sockaddr is 16 bytes.


> (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
>

The standard is rather silent on this matter, hence I don't believe that is
a matter of right or wrong but that this is more a matter of more or less
useful.

The sensible thing to me is to either return the correct amount of relevant
bytes (in this case 8), or zero the additional bytes. I'm sure the Hurd is
already doing the former for AF_UNIX addresses, it's not much of a stretch
to also expect something similar in AF_INET.

And quite frankly, I'd worry more about what data Hurd is leaking…

Also, if one ever wants to add fields to the sockaddr_in (not that that's
very likely), you need to be zeroing it now.


> 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.


That's exactly what we're doing right now.

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