* pull request zeromq#1649 did not contain test

solution :

* add shutdown /init sequence in zsys test

problem : pull request #1649 did not contain test

Solution: reset state if shutdown was clean. Until zeromq#1649, no code
could rely on this, because any attempt to call zsys_init() after
zsys_shutdown() would assert. And zeromq#1649 has not been part of
of any official release yet, so there's no reason to punt this
for reasons of back-compat.

Solution: reset state if shutdown was clean. Until zeromq#1649, no code
could rely on this, because any attempt to call zsys_init() after
zsys_shutdown() would assert. And zeromq#1649 has not been part of
of any official release yet, so there's no reason to punt on
this for reasons of back-compat.

Solution: reset state if shutdown was clean. Until zeromq#1649, no code
could rely on this, because any attempt to call zsys_init() after
zsys_shutdown() would assert. And zeromq#1649 has not been part of
of any official release yet, so there's no reason to punt on
this for reasons of back-compat.

Solution: whenever a pointer is free()'d but not nullifies, a possible
double-free or user-after-free bug is at least potentially possible.
For example zeromq#1649 is in part a spot fix for this problem.  Everywhere in
zmq this is preempted almost as a matter of style. For example, the
destructor pattern in CLASS, and also in zstr_free().  There's little
reason not to replace the calls to free() with a macro that also
nullifies the pointer after free()ing it.  Many project do this and for
good reason, since it eliminates a whole class of bugs.

The only downside is that a double-free no longer triggers a SEGV,
because what is still a logical error is turned into a silent no-op
instead, and it may be the case that the SEGV would have alerted us to
other logical errors. But the caveat also applies to callers of CLASS
destructors and zstr_free(), so it's a tradeoff which has already been
adopted to an extent.

Solution: unify free/nullify into a FREE_AND_NULL macro

whenever a pointer is free()'d but not nullifies, a possible
double-free or user-after-free bug is at least potentially possible.
For example zeromq#1649 is in part a spot fix for this problem.  Everywhere in
zmq this is preempted almost as a matter of style. For example, the
destructor pattern in CLASS, and also in zstr_free().  There's little
reason not to replace the calls to free() with a macro that also
nullifies the pointer after free()ing it.  Many project do this and for
good reason, since it eliminates a whole class of bugs.

The only downside I can see is that a double-free no longer triggers a
SEGV, because what is still a logical error is turned into a silent
no-op instead, and it may be the case that the SEGV would have alerted
us to other logical errors. But the caveat also applies to callers of
CLASS destructors and zstr_free(), so it's a tradeoff which has already
been adopted to an extent.

Solution: unify free/nullify into a FREE_AND_NULL macro

whenever a pointer is free()'d but not nullifies, a possible
double-free or user-after-free bug is at least potentially possible.
For example zeromq#1649 is in part a spot fix for this problem.  Everywhere in
zmq this is preempted almost as a matter of style. For example, the
destructor pattern in CLASS, and also in zstr_free().  There's little
reason not to replace the calls to free() with a macro that also
nullifies the pointer after free()ing it.  Many project do this and for
good reason, since it eliminates a whole class of bugs.

The only downside I can see is that a double-free no longer triggers a
SEGV, because what is still a logical error is turned into a silent
no-op instead, and it may be the case that the SEGV would have alerted
us to other logical errors. But the caveat also applies to callers of
CLASS destructors and zstr_free(), so it's a trade-off which has already
been adopted to an extent.

Solution: unify free/nullify into a FREE_AND_NULL macro

whenever a pointer is free()'d but not nullifies, a possible
double-free or user-after-free bug is at least potentially possible.
For example zeromq#1649 is in part a spot fix for this problem.  Everywhere in
zmq this is preempted almost as a matter of style. For example, the
destructor pattern in CLASS, and also in zstr_free().  There's little
reason not to replace the calls to free() with a macro that also
nullifies the pointer after free()ing it.  Many project do this and for
good reason, as it eliminates a whole class of bugs.

The only downside I can see is that a double-free no longer triggers a
SEGV, because what is still a logical error is turned into a silent
no-op instead, and it may be the case that the SEGV would have alerted
us to other logical errors. But the caveat also applies to callers of
CLASS destructors and zstr_free(), so it's a trade-off which has already
been adopted to an extent.

Solution: unify free/nullify into a FREE_AND_NULL macro

whenever a pointer is free()'d but not nullifies, a double-free or
user-after-free bug is at least potentially possible.  For example zeromq#1649
is in part a spot fix for this problem.  Everywhere in zmq this is
preempted almost as a matter of style. For example, the destructor
pattern in CLASS, and also in zstr_free().  There's little reason not to
replace the calls to free() with a macro that also nullifies the pointer
after free()ing it.  Many project do this and for good reason, as it
eliminates a whole class of bugs.

The only downside I can see is that a double-free no longer triggers a
SEGV, because what is still a logical error is turned into a silent
no-op instead, and it may be the case that the SEGV would have alerted
us to other logical errors. But the caveat also applies to callers of
CLASS destructors and zstr_free(), so it's a trade-off which has already
been adopted to an extent.

Solution: unify free/nullify into a FREE_AND_NULL macro

whenever a pointer is free()'d but not nullifies, a double-free or
user-after-free bug is at least potentially possible.  For example zeromq#1649
is in part a spot fix for this problem.  Everywhere in zmq this is
preempted almost as a matter of style. For example, the destructor
pattern in CLASS, and also in zstr_free().  There's little reason not to
replace the calls to free() with a macro that also nullifies the pointer
after free()ing it.  Many project do this and for good reason, as it
eliminates a whole class of bugs.

The only downside I can see is that a double-free no longer triggers a
SEGV, because what is still a logical error is turned into a silent
no-op instead, and it may be the case that the SEGV would have alerted
us to other logical errors. But the caveat also applies to callers of
CLASS destructors and zstr_free(), so it's a trade-off which has already
been adopted to an extent.

Solution: unify free/nullify into a FREE_AND_NULL macro

whenever a pointer is free()'d but not nullifies, a double-free or
user-after-free bug is at least potentially possible.  For example zeromq#1649
is in part a spot fix for this problem.  Everywhere in zmq this is
preempted almost as a matter of style. For example, the destructor
pattern in CLASS, and also in zstr_free().  There's little reason not to
replace the calls to free() with a macro that also nullifies the pointer
after free()ing it.  Many project do this and for good reason, as it
eliminates a whole class of bugs.

The only downside I can see is that a double-free no longer triggers a
SEGV, because what is still a logical error is turned into a silent
no-op instead, and it may be the case that the SEGV would have alerted
us to other logical errors. But the caveat also applies to callers of
CLASS destructors and zstr_free(), so it's a trade-off which has already
been adopted to an extent.