Hello, I agree that this option is weird, and it's behavior not properly defined (the fd_t stuff). However, shouldn't we mark this option as deprecated instead, and remove it in a later version?
On Fri, Jan 9, 2015 at 6:43 PM, Pieter Hintjens <p...@imatix.com> wrote: > Great :-) > > On Fri, Jan 9, 2015 at 6:38 PM, Thomas Rodgers <rodg...@twrodgers.com> wrote: >> Excellent, I submitted issue 1296 to capture it. I will put together the >> pull req over the weekend. >> >> On Fri, Jan 9, 2015 at 11:26 AM, Pieter Hintjens <p...@imatix.com> wrote: >>> >>> 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 >> >> >> >> _______________________________________________ >> 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 -- Kapp Arnaud - Xaqq _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
