[zeromq-dev] Questions about Coding Style

niXman i.nixman at gmail.com
Sat Feb 11 21:21:07 CET 2012

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 will exclude
memory fragmentation, which is extremely important for the systems

Therefore, in my first email I asked if there are in Community's plans
to implement memory-pool/object-pool/message-pool.

2012/2/11 niXman <i.nixman at gmail.com>:
> 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 <ph at imatix.com>:
>> On Sat, Feb 11, 2012 at 6:27 PM, niXman <i.nixman at 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 not decide how to handle such a situation. Should I use assert
>>> or return EINVAL?
>> Assertions were historically misused in ZeroMQ to handle user errors.
>> They should be used only to assert impossible conditions, i.e.
>> internal errors where continuing is unacceptable. It is (I've used
>> this analogy before) like a cell being highly resistant to invading
>> bacteria and viruses, but self-destructing it if gets a mutation in
>> its DNA.
>> Any remaining cases of asserting on bad input are considered bugs, and
>> can be fixed as such (issue, test case, and patch).
>> Thanks a lot for the code review, this is great.
>> -Pieter
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list