I guess my question is, since 4.1 hasn't been 'released' and is still an rc, can we just avoid the potential downstream heartache all together and remove it?
I'm also fine just marking deprecated and reverting my size check change. On Fri, Jan 9, 2015 at 12:02 PM, Arnaud Kapp <kapp.a...@gmail.com> wrote: > 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 >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
