0.4.0: sys::in_addr_convertion test fails on s390x / IBM System Z (big-endian)

[decathorpe]

---- sys::in_addr_convertion stdout ----
thread 'sys::in_addr_convertion' panicked at 'assertion failed: `(left == right)`
  left: `2130706433`,
 right: `16777343`', src/sys/unix.rs:1450:5

The test passes on on all little-endian architectures I have access to.

• Looking at the code, the to_in_addr function uses from_ne_bytes (equivalent to big-endian?).
• According to std sources, Ipv4Addr::octets() returns the bytes in network-endian order, so that's good.

I think the explicitly "shift-constructed" expected u32 value has the wrong byte order for BE systems, which is apparent when looking at the u32s in binary:

left:   01111111 00000000 00000000 00000001
right:  00000001 00000000 00000000 01111111

The "right" one is the "expected" value I get when calculating 127 | 1 << 24 manually on a little-endian system, but the "left" value definitely has the reversed byte order when constructing it manually on a big-endian system.

[Thomasdezeeuw]

For reference on the current master:

socket2/src/sys/unix.rs

Line 1450 in b1479ff

assert_eq!(a, 127 | 1 << 24);

Do the remainder of the tests pass? Because it might be that the expected value is invalid. Maybe we should use the array syntax, i.e. [127, 0, 0, 1].to_ne_bytes(). Could you try that?

Also does in6_addr_convertion pass? That uses an array for the expected value.

[decathorpe]

Yes, all other tests (including sys::in6_addr_convertion) pass.

I had to do it the other way round ([u32; 4] does not implement to_ne_bytes, so it's a.to_ne_bytes() compared to an array), but I got it to work on both x86_64 and s390x. I'll send a Pull Request :)