Absolutely - so if you build czmq against a newer version of zeromq, and then drop that czmq build into an environment with an older version of zeromq installed, what happens? I think this fails spectacularly right now, even before any of the changes discussed below.
On Thu, Dec 05, 2013 at 02:12:16PM -0500, Lindley French wrote: > The thing about shared libraries is that they can turn logic errors into > runtime errors. Therefore, you need to treat them as such, or else impose a > minimum requirement on the library version and generate a runtime error at > load time if you don't have one that's good enough. > > > On Thu, Dec 5, 2013 at 2:07 PM, AJ Lewis <[email protected]> wrote: > > > Who's only using static linkage? I'm using shared objects and DLLs with > > zeromq and czmq exclusively. > > > > AJ > > > > On Thu, Dec 05, 2013 at 12:12:09PM -0500, Lindley French wrote: > > > This is mostly an academic question so long as libzmq is statically > > linked. > > > If it were ever dynamically linked, it would be much more important to > > get > > > this right. > > > > > > The distinction is similar to what the C++ standard library classifies > > as a > > > "logic error" vs a "runtime error". A logic error means, "Hey, you, > > > programmer. Yes, you. You did something bad. It's your fault I crashed." > > I > > > have no particular problem using asserts to protect against this > > (although > > > if you are literally calling "assert(condition)", be aware these calls > > > disappear when NDEBUG is defined), or in general crashing immediately at > > > this point. Bugs are easier to pin down that way. > > > > > > A "runtime error" means "The code the programmer wrote *could* have > > worked > > > in some cases, but it didn't work this time. Would you like to try > > > something else?" An example might be trying to contact a server which is > > > currently down. Asserts, exits, etc are incredibly inappropriate in these > > > sorts of cases. Use an error code (or an exception in C++), so the > > program > > > has a chance to recover from the problem. > > > > > > In the scenario you describe, it sounds like calling those methods is a > > > logic error. My first impression is that option #1 is the best, on the > > > theory that errors should be caught as soon as possible, and option 1 > > > allows you to catch this error at compile time or link time, instead of > > > waiting for runtime. On the other hand, linker errors can be notoriously > > > difficult to diagnose, so an informative runtime error can sometimes be > > > preferable. > > > > > > > > > On Thu, Dec 5, 2013 at 11:32 AM, Brian Knox <[email protected]> wrote: > > > > > > > To go into more detail: > > > > > > > > Calling zproxy_pause, zproxy_resume, and zproxy_terminate on libzmq > > 2.2 -> > > > > 4.0 does not do anything, as zmq_proxy_steerable was added after 4.0. > > > > > > > > I mulled over three approaches to address this: > > > > > > > > 1) Have an #if ZMQ_VERSION macro that simply removed those methods if > > czmq > > > > is built against a libzmq does does not have zmq_proxy_steerable > > > > 2) Throw an assert if those methods are called when czmq is built > > against > > > > a libzmq that does not have zmq_proxy_steerable > > > > 3) Do nothing, and return a -1 when those methods are called when czmq > > is > > > > built against a libzmq that does not have zmq_proxy_steerable > > > > > > > > My gut was leaning towards going with option #2, but I talked myself > > into > > > > going with option #3 rationalizing that it was "more backwards > > compatible". > > > > > > > > However, since the calls won't actually do anything except return an > > error > > > > code - perhaps exploding via an assert is a more assertive > > communication > > > > that the API user has tried to do something that can not work. > > Thinking > > > > about it, I can't think of a scenario where I would want my code to > > call > > > > these functions when czmq is built against a libzmq that can't support > > them. > > > > > > > > Lindley and Pieter - thank you both for your feedback! > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: [email protected] [mailto: > > > > [email protected]] On Behalf Of Pieter Hintjens > > > > Sent: Thursday, December 05, 2013 11:12 AM > > > > To: ZeroMQ development list > > > > Subject: Re: [zeromq-dev] zproxy (hopefully) improvements > > > > > > > > On Thu, Dec 5, 2013 at 2:52 PM, <[email protected]> wrote: > > > > > > > > > I'm of the opinion that asserts should only be used to signal an > > > > internal problem with the library. Any external interface should > > instead > > > > use error codes if the input is detectably bad. So the question > > becomes, if > > > > you build against a lower version of ZMQ, is that an error or does it > > just > > > > reduce your capabilities? Can you require a minimum version, and check > > this > > > > at init time? > > > > > > > > CZMQ already uses very extensive asserts to catch bad arguments. > > > > Building against a lower version of libzmq is fine. Trying to use > > > > non-existent features is bogus, IMO. > > > > > > > > -Pieter > > > > _______________________________________________ > > > > zeromq-dev mailing list > > > > [email protected] > > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > > > > zeromq-dev mailing list > > > > [email protected] > > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > > > _______________________________________________ > > > zeromq-dev mailing list > > > [email protected] > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > -- > > AJ Lewis > > Software Engineer > > Quantum Corporation > > > > Work: 651 688-4346 > > email: [email protected] > > > > ---------------------------------------------------------------------- > > The information contained in this transmission may be confidential. Any > > disclosure, copying, or further distribution of confidential information is > > not permitted unless such privilege is explicitly granted in writing by > > Quantum. Quantum reserves the right to have electronic communications, > > including email and attachments, sent across its networks filtered through > > anti virus and spam software programs and retain such messages in order to > > comply with applicable data security and retention requirements. Quantum is > > not responsible for the proper and complete transmission of the substance > > of this communication or for any delay in its receipt. > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev -- AJ Lewis Software Engineer Quantum Corporation Work: 651 688-4346 email: [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
