GitLab

Conflicts:
	ChangeLog

Conflicts:
	tests/tools/dhcp-ubench/dhcp-perf-guide.html
	tests/tools/perfdhcp/Makefile.am

The dhcp-perf-guide.html is supposed to be created with make.

 - If it omits setting the counters, which are notifyoutv4, notifyoutv6,
   xfrrej, and xfrreqdone, they are set to None as defaults when the object is
   initiating. Then when each counter is invoked in some method, it checks
   whether the counter is Nonetype or not. Unless the counter is NoneType, it
   invokes the counter.  After that unless the counter is callable, a TypeError
   exception would be raised.

 - added some tests for this changes

 - removed some dead code from xfrout.py.in

TreeNodeRRset::getTTL() is now implemented, so "throw unconditionally" is
simply wrong.
should be trivial enough, directly committing.

regarding the variable name, "local_mem_sgmt_" is now awkward because it's
now of the base class type.

okayed on jabber.

Conflicts fixed:
	src/lib/datasrc/memory/tests/treenode_rrset_unittest.cc
	src/lib/datasrc/memory/treenode_rrset.cc
	src/lib/datasrc/memory/treenode_rrset.h

Conflicts:
	src/lib/dhcp/tests/iface_mgr_unittest.cc

The os.putenv() functionsseems to be not supported on all platforms and
this is indicated in the python documentation.

For some reason, the Python "os.putenv()" did not work, so changed
to morifying the "os.environ" variable directly.

This fixes memory leak reported by Valgrind. Dicussed with Jelte on jabber.

addFromLoad() used to throw before, but now the called code itself
throws.  add() should never return anything except SUCCESS, so if it
returns anything else, we assert.

This is so we can differentiate between whether a node was not found
and whether a node was found, but its old data was empty.

We also don't set the node data now when an exact match was not found.
Before it used to set for partial matches too (which was a bug).

Strictly, this is done to silence clang-analyzer. In every case,
parseAnswer() does set rcode (which is passed by reference) unless it
throws.  It looks like clang-analyzer gets confused by the exception
paths.

In any case, it's good to initialize it to the unexpected case and not
depend on parseAnswer().

The assert() should silence clang-analyer.

These are not required according to:
http://docs.python.org/py3k/extending/extending.html?highlight=null#null-pointers

These NULL checks cause static analysis reports in other parts of the
code where the pointers are not NULL tested before use.

Reported by clang-analyzer.