[zeromq-dev] Questions about Coding Style

[Chuck Remes]

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.

cr