typo Virtaul -> Virtual in class group name
Merge pull request #1373 from estenberg/bugfix/class-tag-group-typo

typo Virtaul -> Virtual in class group name
ChangeLog edit
Typecheck FnCalls in VerifyVarPromise
Fix uninitialized memory reads.

In StringWriterWriteLen(), using strlen() and strlcpy() are
problematic when the input comes from read(), which doesn't terminate
its data.  In particular, relying on copying one more byte then the
string length as a way to get a '\0' in place is unsound; there may be
no '\0' at str[len_+1].  So use strnlen(), memcpy() and add the final
'\0' explicitly.

Fixed another place where strnlen() is the right answer, too; and
tidied a comment's layout.
Don't putenv() a local auto buffer.

As putenv() doesn't copy its input, you need persistent storage.
Rather than leak a strndup() or add a static buffer, simply use setenv().
Pass persistent copy to putenv().

The scalar packaged by an Rlist entry gets free()d eventually; so it's
not a good thing to pass to putenv().  Passing a strdup() of the entry
is leaky, but the best I can see to do right here.  Hopefully it
doesn't happen often ...
Code-reviewers didn't like a down-counting for loop.

So use a while loop instead.
Free release_id when PolicyMerge destroys a policy.
Don't leak policy object in cf-agent's main().

Not a big deal, but keep valgrind happy.
Leak-fix in StringMatchCaptures(): don't leak locals.

Also, use pcre_free() on the pcre* we need to release, not free().
Fix leakage of lists of gid and uid entries.

GetPermissionConstraints() hangs some allocated objects off the .perms
field of an Attributes object.  Attributes objects generally only
carry copies of data elsewhere, but the .owners and .groups members of
.perms now need to be deleted properly when the Attributes object goes
away.  So let's not make GetPermissionConstraints() public any more
(it has no other callers, so let's not solicit more) and we need a
public companion to GetFilesAttributes(), that cleans up its return
when its caller is finished with the Attributes object.  Add that
companion, ClearFilesAttributes(), and call it from the (fortunately
only) one place that calls GetFilesAttributes().  It, in turn, needs
[UG]idListDestroy() functions that tidy away the respective lists.
(How did someone write Rlist2[GU]idList(), returning allocated
pointers, and not notice the need for clean-up functions for those
pointers ?)
Leak fix: RlistAppendScalar{,Idemp}(..., xstrdup(...))

Since RlistAppendScalar makes its own copy, passing in a strdup() of
your data is necessarily a leak; no-one's going to be holding onto
your strdup()'s return afterwards.
Make loop more evidently correct.

Each path round the loop (it continue;s in two places) was setting the
running pointer to the ->next of the previous iteration's item; unify
how that's done so as to make it obviously correct, rather than
obliging the reader to work out what's happening.  Incidentally gives
the optimiser a bit of scope for doing better (because *it's* also
more likely to realise what's actually happening here).
Leak-fix: ExpandDanglers expanded a copy and returned a copy of it.

Passing the expanded copy to RvalNew() makes a fresh copy; so the copy
used for expansion got leaked.  Return it raw, instead of via a
copying constructor.
Leak-fix: tidy return from StringMatchCaptures() on early returns.

A loop in FnCallFormat had some early returns that neglected to tidy
away the string list returned when parsing a format string and the
following text.
Leak-fix: another double-copy via RvalNew.

Passing RvalNew a copy of the data for the new object just duplicates
RvalNew()'s own copying of the data.
Break up some long lines.
Tidy-up in EvaluateFinalRval().

Added some assertions.  Make explicit a dependence on list items being
scalars or fncalls.  Reverse an if (!cond)...else... to use a positive
test.  Use else if rather than else { if ... }.  Shuffle some
replacements to a common pattern (remember old value, overwrite, tidy
away old) to make it easier to follow them all.
Leak-fix: another double-copy when constructing.

FnCallNew() copies the given args for its new object; so FnCallCopy()
shouldn't also be copying (without deleting later) what it passes
down.  Also tidied FnCallNew() slightly.