comments.

I commented on how LengthBuffers work.
reflow comment
bugfix: getClientInfo access violation

getClientInfo was poking 0 into an area of memory that had already been
freed.
bug fix: LengthBuffer wasn't freeing itself.

the DhcpStructure produced by `lengthBuffer` contained a free function
which freed elements of the array, but not itself.
extra strictness in LengthBuffer
Add RankNTypes to a few modules
Split freeing of parent object from children

The 'DhcpStructure a' dictionary object has always had a function named
'freeDhcp'. For most structures, this would recursively free all child
structures before freeing the "parent" pointer supplied to the
function.

There is at least one case where this final step was not desired. The
'hostInfo :: DhcpStructure HOST_INFO' declaration didn't free the parent
because on the C side its structure was inlined within a
'ClientInfoV4'. There was another case with 'DhcpStructure (LengthBuffer
a)' where I should have been freeing the parent pointer, but was not.

The 'DhcpStructure a' dictionary now contains a member named
'freeDhcpChildren' which makes it clear that the main pointer will not
be freed. There is a separate function outside the dictionary named
'freeDhcp' which simply calls 'freeDhcpChildren' before freeing the main
pointer.

Most call sites were left as before, and code dealing with 'HOST_INFO'
isn't a special case.
LengthArray variants clean up buffer spine

LengthArrays are created by specifying a "flavor" of array. Available
options include baseArray, basicArray, and ptrArray. The difference has
to do with how the underlying buffer is layed out in memory. Previously
the baseArray and basicArray variants were failing to free the spine of
the buffer before the lengthArray itself was freed.
replace 'freeptr' with "scrubbing" family

I replaced the 'freeptr' function with a more general "scrubbing" family
of functions. These perform an action over the pointer within a doubly
referenced pointer if and only if no access violation would occur. It
then returns the result of that action wrapped in a 'Maybe'. A nothing
indicates that the embedded pointer had a value of 0.
use "scrubbing" family in memory cleanup
bugfix: access violation with 0-length arrays
enum functions ignore read and total out vars

The enumSubnetElementsV4 and enumSubnetClientsV4 are simplified to
ignore the elementsRead and elementsTotal out vars. MSDN documentation
advices that these be referred to deciding whether to call the function
additional times with a resumeHandle.

In my testing I've found that the elementsTotal function always returns
0x7fffffff until the final call. elementsRead does return a useful
value, but not for my use case. In either case, the only thing to watch
for when deciding whether to call the enum function additional times is
the return value.
simply front-end functions with scrubWith
version bump