From 08784c38238e7716ea92bda67ff2d22cbecf8ed9 Mon Sep 17 00:00:00 2001 From: Jan Niehusmann Date: Sat, 17 Feb 2024 11:37:21 +0000 Subject: [PATCH] zmq_sys::ZMQ_RCVMORE returns a c_int 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 '' 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.) --- src/lib.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/lib.rs b/src/lib.rs index 17dc0ccd..8439d527 100644 --- a/src/lib.rs +++ b/src/lib.rs @@ -802,7 +802,7 @@ impl Socket { /// Return true if there are more frames of a multipart message to receive. pub fn get_rcvmore(&self) -> Result { - sockopt::get(self.sock, zmq_sys::ZMQ_RCVMORE as c_int).map(|o: i64| o == 1i64) + sockopt::get(self.sock, zmq_sys::ZMQ_RCVMORE as c_int).map(|o: i32| o == 1i32) } sockopts! {