zmq 3.x introduces problem with ZMQ_RCVMORE and uint64_t
Description
Environment
Ubuntu 12.04 Linux kernel 3.2, GCC 4.6
Activity

PieterP May 30, 2014 at 9:18 AM
I've fixed zhelpers.c.
Many/most integer socket options were changed to int in 3.2, as explained in the upgrade docs: "* Most but not all socket options are now ints."
The C++ translations are contributed by users so if you want to change them, could you send a pull request?
I think we can close this issue now.

Johan Ström May 27, 2014 at 9:34 AM
Reopening as this hit me too, and this should at least be mentioned in http://zeromq.org/docs:3-1-upgrade.
At least some examples seems to require an update as well:
https://github.com/imatix/zguide/blob/master/examples/C/zhelpers.h
https://github.com/imatix/zguide/blob/master/examples/C%2B%2B/rrbroker.cpp
https://github.com/imatix/zguide/blob/master/examples/C%2B%2B/zmsg.h
https://github.com/imatix/zguide/blob/master/examples/C%2B%2B/wuproxy.cpp

Liu, Kun September 13, 2012 at 1:23 PM
Looks like in socket_base.cpp
, it is using int
as the value type and passing back the size of the value type:
So your code seems should change to
Don't know if it is intended though.

Ian Barber August 31, 2012 at 5:23 PM
This happened about a year ago in 3.x - the value expected is now an int, not a uint64_t (which is was in 2.x). The documentation has been updated to reflect, but I appreciate that's not always the first place you check!
We use a forwarding function to forward a message from one socket to another. To forward all message parts, we read the ZMQ_RCVMORE socket option:
After upgrading to zmq 3.2 this code no longer works. The reason is that not always, but at certain points, the
more
value would be neither 0 nor 1 but a huge number such as 1234005123. Changingmore
's type fromuint64_t
touint32_t
fixes the issue for now.Our setup is as follows:
< DEALER > - inproc -> < ROUTER > - ipc -> < ROUTER > - tcp -> < DEALER >
The forwarding shows the strange behavior when receiving from ipc and trying to forward to tcp.
This is not intended behavior in my opinion. It would also break using platform native
int
on x64 platforms.