zmq_getsockopt with the option ZMQ_RCVMORE returns an 'int' value. However, get_rcvmore interpreted the result as an i64. While this is technically wrong in case c_int is 32 bit wide, it seems to still work in most cases, as the bit representation of 1i32 and 1i64 is identical on little-endian systems.
However, on big-endian systems, it fails. This can be reproduced on the debian s390x port, where cargo test fails with:
test test_monitor_events ... FAILED
failures:
---- test_monitor_events stdout ----
thread '<unnamed>' panicked at 'assertion failed: server.get_rcvmore().unwrap()', tests/monitor.rs:47:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'test_monitor_events' panicked at 'called `Result::unwrap()` on an `Err` value: Any { .. }', /home/jan/.cargo/registry/src/github.com-eae4ba8cbf2ce1c7/timebomb-0.1.2/src/lib.rs:45:18
To fix this, get_rcvmore should interpret the return value as an i32.
(Technically, c_int would be more correct than i32. But the getter generated by getsockopt_num!(c_int, i32) in src/sockopt.rs already maps c_int to i32. This may be an issue on systems where c_int is a 16 bit value. But I doubt zmq will be used on such a system in practice.)
zmq_getsockopt with the option ZMQ_RCVMORE returns an 'int' value. However, get_rcvmore interpreted the result as an i64. While this is technically wrong in case c_int is 32 bit wide, it seems to still work in most cases, as the bit representation of 1i32 and 1i64 is identical on little-endian systems.
However, on big-endian systems, it fails. This can be reproduced on the debian s390x port, where
cargo testfails with:To fix this,
get_rcvmoreshould interpret the return value as ani32.(Technically,
c_intwould be more correct thani32. But the getter generated bygetsockopt_num!(c_int, i32)insrc/sockopt.rsalready mapsc_inttoi32. This may be an issue on systems wherec_intis a 16 bit value. But I doubt zmq will be used on such a system in practice.)