[zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk

Pieter Hintjens ph at imatix.com
Fri Jan 9 18:26:45 CET 2015

Sounds good.

On Fri, Jan 9, 2015 at 6:00 PM, Thomas Rodgers <rodgert at twrodgers.com> wrote:
> I would like to propose removing this option before it becomes part of an
> officially released API, but I would like to reassurance that this is an
> appropriate course of action before doing so.
> My reasoning for removing it is as follows -
> * It is the only option to zmq_getsockopt() that treats option_value as a
> value/result parameter, all others treat option_value as strictly a result
> parameter.
> * A brief survey of the Posix getsockopt() API shows a similar lack of using
> option_value as a value/result parameter.
> * The original implementation requires the caller to ensure that the
> returned buffer is sufficient to hold an fd_t, but fd_t is not part of
> ZeroMQ's public API. It is conditionally defined by platform and on Windows
> has two potential definitions.
> * I'm not comfortable with this blind faith assignment through a pointer, so
> I submitted a length check change. Unfortunately this introduces a whole new
> class of potential usage problems for this option.
> * I don't know what the intended use case for the option is, but I infer
> from the test_id2fd test case, that is to build a map of router identity to
> fd, perhaps to pass fd to getpeername(2) and build a map of identity to
> peername. If this is indeed the case, this use case is already handled by
> calling zmq_msg_get(&part, ZMQ_SRCFD), on the message part containing the
> identity frame.
> What am I missing here?
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list