Status of changes

[Alan DeKok]

  I started to remove 'lvalue' from VALUE_PAIR, in the theory that we
can use the union of data types for something else.  It turns out we
can't, at least until we audit the code for things that print to
vp_strvalue for integer/date/ipaddr types.

  I've also started removing the references to "paircreate" from the
server source, and replacing them with a wrapper function.  It turns out
that all of the calls in the core && modules did the same thing:

	vp = paircreate()
	if (!vp) OOM
	pairadd(...)

  So replacing all that with 1 line of code makes a difference.  Plus,
it centralizes the place where VP's are allocated (one function).  It
also passes the REQUEST* to that function, which lets us move to memory
pools later.  According to callgrind, memory free/alloc is a significant
cost in the server (~15%).  So fixing that will make a big difference.

  I plan on doing the same thing with pairmake().  Almost all of the
calls to pairmake() are with fixed attribute names.  So they should be
replaced with calls to paircreate(), with the attribute number
hard-coded in.

  It's a lot of repetitive grunt work, but it's laying the foundation
for some useful changes in the future.

  I think I also have an idea for how HUP can be handled without killing
the server, and without large amounts of complexity.  More later, as I
flesh it out.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog