The "count_" out-parameter is doubled instead of unchanged.

Static analysis says:
src\zmq.cpp(489): error V220: Suspicious sequence of types castings: memsize -> 32-bit integer -> memsize. The value being casted: '* count_'.
src\zmq.cpp(510): error V127: An overflow of the 32-bit 'nread' variable is possible inside a long cycle which utilizes a memsize-type loop counter.

I've silenced the warning on line 489 and ignored the other.
But also, it looks to me like there's a serious bug here: The
out-parameter "count_" is never set to zero before we start
incrementing it. So its final value will always be between
1 and 2 times its initial value. The fix seems obvious.
Silence a compiler warning.

Static analysis says:
src\fd.hpp(38): error V103: Implicit type conversion from memsize to 32-bit type.

Adding the explicit cast should shut it up.
Fix a bug in pipe_t::flush().

Static analysis says:
src\pipe.cpp(193): error V547: Expression is always false. Probably the '||' operator should be used here.

If flush() is called on a pipe whose state was
"terminated" or "double_terminated", the programmer's
intent was to return immediately. But in fact the
two conditions can never be true simultaneously, so
the early return never happens, and we may try to flush
a terminated pipe anyway.
Add a missing null-check, turning a segfault into an assertion.

Static analysis says:
src\tcp_address.cpp(297): error V595: The 'res' pointer was utilized before it was verified against nullptr. Check lines: 297, 301.
src\tcp_address.cpp(603): error V106: Implicit type conversion third argument 'full_bytes' of function 'memcmp' to memsize type.
src\tcp_address.cpp(603): error V526: The 'memcmp' function returns 0 if corresponding buffers are equal. Consider examining the condition for mistakes.

In fact the use of "memcmp" is correct, but the enclosing "if" isn't
necessary, and the compiler is happier if "full_bytes" is a size_t.
Fix monitor_event() to work at all.

There are three versions of monitor_event(), all taking
variadic arguments. The original code just has the first one
creating a va_list and passing that va_list variadically to
the second one... which creates a new va_list and passes it
variadically to the third one... and of course everything
blows up when we try to pull a non-va_list argument off the
stack.

The correct approach matches the C standard library's use
of printf/vprintf, scanf/vscanf, and so on. Once you make
a va_list, you must pass it only to functions which expect
a va_list parameter.
Merge pull request #413 from Quuxplusone/static-analysis

Various bugfixes found by compiling with extra warnings
Fixing incorrect argument order on va_start

Compile was failing on the monitor_event function function due to the
va_start params being switched.
Incorrect var name in monitor_event

The call to the va version of the function was using 'event' instead of
'event_'
Incorrect function name in socket_base

VA specific monitor event in socket base was named monitor_event rather
than va_monitor_event
Remove early return on terminated state

Code as stands breaks shutdown process. It was a bugfix by Arthur to a
bad line which was testing for an impossible state - but afaics we do
actually want to flush in those states. It is possible I am wrong on
that though - if there are any shutdown issues introduced aroudn this
commit I would suggest further investigation around this flushing
behavior.
Use full endpoint string in monitor response

The endpoint was excluding the tcp://, causing tests to fail
Update ROUTER_BEHAVIOR documentation

Include a note about potential interactions with reactors, and update
reference to old FAIL_UNROUTABLE name.
Merge pull request #414 from ianbarber/master

Fix build breaking typos in monitor VA code