Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk
I'm also fine just marking deprecated and reverting my size check change. No don't do this! Preventing memory corruption can only be a good thing. I agree, but basically makes it completely unusable in certain use cases (as you so eloquently put it, this option is 'weird'). Anyway, unless there is strong consensus for deprecation, I am going to unwind the whole thing. On Fri, Jan 9, 2015 at 12:13 PM, Arnaud Kapp kapp.a...@gmail.com wrote: I'm also fine just marking deprecated and reverting my size check change. No don't do this! Preventing memory corruption can only be a good thing. It wasn't part of any release (except pre-release). Oh I didn't realize it was that new. Well in that case, if we're going to remove it we might as well do it now indeed. On Fri, Jan 9, 2015 at 7:07 PM, Peter Kleiweg pklei...@xs4all.nl wrote: Arnaud Kapp schreef op de 9e dag van de louwmaand van het jaar 2015: 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? It wasn't part of any release (except pre-release). -- Peter Kleiweg http://pkleiweg.home.xs4all.nl/ ___ 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
Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk
Excellent, I submitted issue 1296 https://github.com/zeromq/libzmq/issues/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
Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk
Arnaud Kapp schreef op de 9e dag van de louwmaand van het jaar 2015: 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? It wasn't part of any release (except pre-release). -- Peter Kleiweg http://pkleiweg.home.xs4all.nl/ ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk
I'm also fine just marking deprecated and reverting my size check change. No don't do this! Preventing memory corruption can only be a good thing. It wasn't part of any release (except pre-release). Oh I didn't realize it was that new. Well in that case, if we're going to remove it we might as well do it now indeed. On Fri, Jan 9, 2015 at 7:07 PM, Peter Kleiweg pklei...@xs4all.nl wrote: Arnaud Kapp schreef op de 9e dag van de louwmaand van het jaar 2015: 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? It wasn't part of any release (except pre-release). -- Peter Kleiweg http://pkleiweg.home.xs4all.nl/ ___ 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
Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk
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] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk
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
Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk
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
Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk
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
Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk
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
Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk
Thomas Rodgers schreef op de 9e dag van de louwmaand van het jaar 2015: 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? Seems sensible to me. The same goes for the socket options ZMQ_IPC_FILTER_PID, ZMQ_IPC_FILTER_UID, ZMQ_IPC_FILTER_GID. -- Peter Kleiweg http://pkleiweg.home.xs4all.nl/ ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
