There are five cases for the types declared for options in [gs]etsockopt():
1. 64 bits, unsigned: AFFINITY, SNDBUF, RCVBUF. 2. 64 bits, undefined (presumably signed): SWAP, RATE, RECOVERY_IVL, MCAST_LOOP, RCVMORE. 3. 32 bits, unsigned: HWM, EVENTS. 4. 32 bits, undefined (presumably signed): ZMQ_TYPE. 5. Might be variable: this is the case for ZMQ_FD, which on Windows could be the same as UINT_PTR or SOCKET, and on others is int (plain int, not signed or unsigned, no specific size). This makes it difficult to keep track of the appropriate sizes. The bindings have to deal with all this variability as well. Questions / proposals: 1. Can we make all of them 32 OR 64 bits? Or do we really need to have some be 32 bits and some be 64 bits? 2. Can we make all of them signed OR unsigned? Or de we really need to have some be unsigned and some be signed / unspecified (this last looks like a bad idea)? 3. Can we change the typedefs (or include new ones) so that the signedness is explicit (sint32_t, sint64_t, etc., rather than / in addition to int32_t, int64_t, etc.)? 4. Can we choose a specific size (perhaps 64 bits) and signedness (perhaps unsigned) for ZMQ_FD? In short, a simple (but perhaps incorrect) proposal would be to have all of them be unsigned 64 bits, using uint64_t. When we reach consensus, I can do the changes to the code. -- Gonzalo Diethelm _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
