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 _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
