[zeromq-dev] Questions about Coding Style

Peter Alexander peteralexander at prodatalab.com
Sat Feb 11 19:43:03 CET 2012


On Sat, Feb 11, 2012 at 12:37 PM, Chuck Remes <cremes.devlist at 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
>>>> when the program will be crushed on segmentation fault.
>>>
>>> It's impossible to avoid this in C.
>>
>> That's bollocks.
>>
>>>> I consider that programs crash on segmentation fault is an
>>>> inadmissible error of the ØMQ developers', but not the library user's.
>>>
>>> No. The right thing is: the library is only responsible if the
>>> pre-conditions of the function call are met. If the pre-conditions
>>> of the call are not met, all bets are off.
>>
>> This is *EXACTLY* the attitude that people took who created the various libraries and the users who followed their example that has given C this particularly bad reputation.
>>
>> There's certainly a realm of things way out beyond the boundaries that are beyond the reasonable control of a library like 0mq. Taking care to deal with basic, fundamental errors of parameters to functions is NOT one of them.  This is a huge, lazy, cop out and, IMHO, seriously hurts the adoption of 0mq by people/organizations who need something they can have full faith and trust in to run robustly.
>>
>> This is critically important for the growth of 0mq out beyond it's traditional/historical community in the big financials. I.e. out in the wilderness where the networks aren't all high-speed and local; where there aren't operators on-call 24x7; where all of the other end-points are all basically well-behaved; where the programmers aren't living and breathing this stuff all day long; etc.
>>
>> I understand your personal bias to drive people to other, "better" languages and applaud your efforts in actually creating a language. But the fact is that 0mq is a multi-language solution by design and so there's no hand waving away this very fundamental flaw.
>
> I agree 100% with Mr. Mitchell.
>
> I will aggressively merge patches that make 0mq a safer and more "forgiving" library. As a binding author and maintainer, I can't count the number of times that I made a stupid mistake that my error handling mechanisms would catch but 0mq puked instead. Validation of arguments is a pretty easy operation and one that I encourage for libraries.
>
> I have heard of a "rule" that sounds pretty reasonable for libraries: Be strict in what you output but tolerant in what you accept as input.

Hi all, when it comes to critical systems programming, I simply turn
to the Linux kernel developer's coding standards, styles and
conventions. Done.

just my humble $0.02.

~Peter
a.k.a. travlr

>
> cr
>
> _______________________________________________
> 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