Sounds good.
On Fri, Jan 9, 2015 at 6:00 PM, Thomas Rodgers <rodg...@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@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
