On Sun, Feb 12, 2012 at 9:28 PM, Gary Wright at2002+...@me.com wrote:
ruby client code = ruby binding = libzmq C binding = C++ core
So I would just apply the principle described above to each interface.
The C++ code should use error codes/exceptions according to C++ idioms.
The libzmq C
On Feb 12, 2012, at 4:40 PM, Mikko Koppanen wrote:
On Sun, Feb 12, 2012 at 9:28 PM, Gary Wright at2002+...@me.com wrote:
ruby client code = ruby binding = libzmq C binding = C++ core
So I would just apply the principle described above to each interface.
The C++ code should use error
On 13/02/2012, at 8:28 AM, Gary Wright wrote:
ruby client code = ruby binding = libzmq C binding = C++ core
I actually think this is a problem. Basically, the C binding is just that:
it's just another binding. What I mean is, there should probably be two
interfaces:
1) Core interface, to be
On 13/02/2012, at 9:24 AM, Gary Wright wrote:
Perhaps the solution is to have two interfaces to the library.
Heh! I just wrote that too.
A
'paranoid' interface that reports errors as much as possible and a
'go wild' interface that simply assumes that everything has been
checked. The
On Feb 12, 2012, at 5:01 PM, john skaller wrote:
On 13/02/2012, at 9:24 AM, Gary Wright wrote:
Perhaps the solution is to have two interfaces to the library.
Heh! I just wrote that too.
I think allowing bindings to go directly to the C++ core interface will be
problematic for a lot of
On 13/02/2012, at 12:29 PM, Chuck Remes wrote:
I think allowing bindings to go directly to the C++ core interface will be
problematic for a lot of languages. Many languages interface to libzmq via
FFI which, as far as I know, doesn't support C++ in any way, shape or form.
These languages
Hello list.
Continuing review of the libzmq code, I have found a few situations
when the program will be crushed on segmentation fault. On the one
hand, it is possible to refer to an error because of the user. But on
the other hand, Coding Style says: Assertions say that the ØMQ
developers do not
On 11/02/2012, at 8:27 PM, niXman wrote:
Continuing review of the libzmq code, I have found a few situations
when the program will be crushed on segmentation fault.
It's impossible to avoid this in C.
I consider that programs crash on segmentation fault is an
inadmissible error of the
2012/2/11 john skaller skal...@users.sourceforge.net:
On 11/02/2012, at 8:27 PM, niXman wrote:
Continuing review of the libzmq code, I have found a few situations
when the program will be crushed on segmentation fault.
It's impossible to avoid this in C.
I consider that programs crash on
On 11/02/2012, at 9:23 PM, niXman wrote:
In the example above, it is enough to add check on null pointer ( if
(optvallen_ !(optval_)) {} ). This gives to the user more
information about the error, instead of the silent crash.
Agreed.
Regarding the check of pointers of sockets, everything
2012/2/11 john skaller skal...@users.sourceforge.net:
On 11/02/2012, at 9:23 PM, niXman wrote:
In the example above, it is enough to add check on null pointer ( if
(optvallen_ !(optval_)) {} ). This gives to the user more
information about the error, instead of the silent crash.
Agreed.
On Sat, Feb 11, 2012 at 11:06 AM, niXman i.nix...@gmail.com wrote:
Meanwhile, even my simple patch [1] isn't accepted.
[1] https://github.com/zeromq/libzmq/pull/240
... it's been a day. You need to consider resetting your expectations of
open source communities.
Ian
On 11/02/2012, at 10:06 PM, niXman wrote:
Before writing something, I want to understand the attitude of the
project Administrators to innovations, and their readiness to take
measures for improving libzmq.
It's fairly clear in the policy.
Meanwhile, even my simple patch [1] isn't
2012/2/11 john skaller skal...@users.sourceforge.net:
On 11/02/2012, at 10:06 PM, niXman wrote:
Before writing something, I want to understand the attitude of the
project Administrators to innovations, and their readiness to take
measures for improving libzmq.
It's fairly clear in the
On Feb 11, 2012, at 5:06 AM, niXman wrote:
Before writing something, I want to understand the attitude of the
project Administrators to innovations, and their readiness to take
measures for improving libzmq.
Meanwhile, even my simple patch [1] isn't accepted.
[1]
2012/2/11 Chuck Remes cremes.devl...@mac.com:
On Feb 11, 2012, at 5:06 AM, niXman wrote:
Before writing something, I want to understand the attitude of the
project Administrators to innovations, and their readiness to take
measures for improving libzmq.
Meanwhile, even my simple patch [1]
Good morning,
On Feb 11, 2012, at 01:51 , john skaller wrote:
On 11/02/2012, at 8:27 PM, niXman wrote:
[...]
Continuing review of the libzmq code, I have found a few situations
when the program will be crushed on segmentation fault.
It's impossible to avoid this in C.
That's bollocks.
I
On Feb 11, 2012, at 10:53 AM, John D. Mitchell wrote:
On Feb 11, 2012, at 01:51 , john skaller wrote:
On 11/02/2012, at 8:27 PM, niXman wrote:
[...]
Continuing review of the libzmq code, I have found a few situations
when the program will be crushed on segmentation fault.
It's impossible
On Sat, Feb 11, 2012 at 12:37 PM, Chuck Remes cremes.devl...@mac.com wrote:
On Feb 11, 2012, at 10:53 AM, John D. Mitchell wrote:
On Feb 11, 2012, at 01:51 , john skaller wrote:
On 11/02/2012, at 8:27 PM, niXman wrote:
[...]
Continuing review of the libzmq code, I have found a few situations
On Sat, Feb 11, 2012 at 6:27 PM, niXman i.nix...@gmail.com wrote:
For example the call:
rc = zmq_setsockopt (sub, ZMQ_SUBSCRIBE, 0, 4);
will end on segmentation fault on line 56 of the sub.cpp file.
According to the documentation, if an error occurs, the function
should return -1.
I can
I'm confused ...
Do you all agree with that the arguments must be checked? And with the
fact that in case of error of arguments is not necessary to use assert
but set errno and return -1?
2012/2/11 Pieter Hintjens p...@imatix.com:
On Sat, Feb 11, 2012 at 6:27 PM, niXman i.nix...@gmail.com
On 12/02/2012, at 3:53 AM, John D. Mitchell wrote:
Good morning,
On Feb 11, 2012, at 01:51 , john skaller wrote:
On 11/02/2012, at 8:27 PM, niXman wrote:
[...]
Continuing review of the libzmq code, I have found a few situations
when the program will be crushed on segmentation fault.
On 12/02/2012, at 4:37 AM, Chuck Remes wrote:
I will aggressively merge patches that make 0mq a safer and more forgiving
library.
No you won't :)
You want a robust check? I can give you 99.%.
But you'll pay.
You already griped about the tiny weeny cost of my thread safe
sockets (two
The problem with dangling pointers can only be solved using its own
allocator. Thus, any address (pointer), not found among the selected
blocks - is considered hanging.
This, in its turn will not only reduce the number of errors, but that
is not unimportant - will increase system reliability and
On 12/02/2012, at 6:47 AM, niXman wrote:
I'm confused ...
Do you all agree with that the arguments must be checked? And with the
fact that in case of error of arguments is not necessary to use assert
but set errno and return -1?
IMHO, if you do a check for a NULL pointer you should use
On 12/02/2012, at 7:21 AM, niXman wrote:
The problem with dangling pointers can only be solved using its own
allocator.
Sort of. You don't need to actually write an allocator.
It is enough to trace all constructed sockets.
This won't stop memory corruption of a legitimately constructed
live
On Feb 11, 2012, at 1:47 PM, niXman wrote:
I'm confused ...
Do you all agree with that the arguments must be checked? And with the
fact that in case of error of arguments is not necessary to use assert
but set errno and return -1?
I think this is reasonable. If the community doesn't like
On Feb 11, 2012, at 2:14 PM, john skaller wrote:
On 12/02/2012, at 4:37 AM, Chuck Remes wrote:
I will aggressively merge patches that make 0mq a safer and more forgiving
library.
No you won't :)
You want a robust check? I can give you 99.%.
But you'll pay.
John, why do you
On 12/02/2012, at 7:44 AM, Chuck Remes wrote:
On Feb 11, 2012, at 2:14 PM, john skaller wrote:
On 12/02/2012, at 4:37 AM, Chuck Remes wrote:
I will aggressively merge patches that make 0mq a safer and more
forgiving library.
No you won't :)
You want a robust check? I can give
On 12/02/2012, at 8:03 AM, niXman wrote:
Sort of. You don't need to actually write an allocator.
It is enough to trace all constructed sockets.
And what to do with pointers to the data for zmq_recv (), for example?
void *data = 0x3423e65;
zmq_recv(sock, data, 32, 0);
Of course, the
On Sun, Feb 12, 2012 at 4:47 AM, niXman i.nix...@gmail.com wrote:
Do you all agree with that the arguments must be checked? And with the
fact that in case of error of arguments is not necessary to use assert
but set errno and return -1?
Up to a point. Some invalid arguments are best handled
On Feb 11, 2012, at 3:15 PM, john skaller wrote:
On 12/02/2012, at 7:44 AM, Chuck Remes wrote:
John, why do you make this more complex than it needs to be?
I'm making a point. There are alternate viewpoints,
and compromises in between. Both viewpoints are valid,
as are compromises in
On Feb 11, 2012, at 4:53 PM, Pieter Hintjens wrote:
So in my libraries, like CZMQ, I validate input arguments with
asserts, systematically.
And yet for some language bindings it would be more idiomatic to
raise an exception, rather than just have the process terminate. If
libzmq returned an
On 12/02/2012, at 11:40 AM, Gary Wright wrote:
On Feb 11, 2012, at 4:53 PM, Pieter Hintjens wrote:
So in my libraries, like CZMQ, I validate input arguments with
asserts, systematically.
And yet for some language bindings it would be more idiomatic to
raise an exception, rather than
34 matches
Mail list logo
