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 >>>> 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@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
