Solution:
Mark them with LIBZMQ_UNUSED macro as per convention; although in future the
appropriate pthread code should be updated to support thread scheduling
priorities (for Mac OS X, et. al.)
The TIPC protocol bindings in ZeroMQ defaults to a lookup domain
of 1.0.0 to prevent 'closest first' search, and instead always
do round robin if several sockets in the network or node have
the same name published. In retrospect, this might have been a
bad idea because it won't work on standalone configurations.
We solve this by allowing an optional domain suffix to be provided
in the address, and 0.0.0 should be used in that case, or if the
TIPC address range in the cluster configuration is defined to some
other value. Domain suffixes are only relevant for connecting
addresses.
Signed-off-by: Erik Hugne <erik.hugne@gmail.com>
Solution:
This is an issue with the imported Autoconf M4 macro package for standardised
code coverage builds, i.e. using --enable-code-coverage.
The simplest way that I could find is to add a case statement that checks if
the output of running `gcov -version` contains the "LLVM" keyword; if that is
true then do not link with LIBGCOV as its neither required nor supported when
using the GCOV frontend for LLVM; least not on Mac OS X. The case statement
would also be the most portable.
Moreover, using the "-version" argument instead of "-v" seems to be the best
bet as that is supported by the normal GCOV and LLVM GCOV frontend.
Upstream candidate - this solution should be improved by Autoconf M4 macro
overlords and applied to the upstream M4 package; I could not find a suitable
way to detect if LLVM GCOV is being used, except for the solution herein; this
should also work on *BSD too.
Solution: Use travis to deploy these artifacts automatically.
The deployment is triggered by tagging on the zeromq/libzmq repository.
Of the many builds travis is checking only the default one with
libsodium and drafts disabled is used for deployment.
For now the results of `make distcheck` are deployed as well as their
md5 and sha1 hash sums. Further changes may upload a generated
Changelog as well.
Solution:
- Add file for testing ancillary API methods and any misc internal machinery
- Add tests for zmq_version(3) and zmq_strerror(3)
- Add test file into gitignore, Autotools and CMake build files
- Increase test coverage
Note:
MSVC solution files have not been updated.
Solution:
Add CMake option called WITH_MILITANT so that it aligns with the Autotools
build infrastructure; enabling this option defines ZMQ_ACT_MILITANT, which
enables assertions should malformed requests make their way into
zmq_setsockopt(3) or zmq_getsockopt(3).
Solution:
As preparation for 4.2 release, move the zmq_sendiov and zmq_recviov API
methods under the Deprecated Methods section.
Note: the actual methods have NOT been deprecated yet, functionally speaking
however it is good to let API users know early. Moreover, these methods were
not ever considered stable, at least according to src/zmq.h, and have no
associated man pages.
