[libvirt] [PATCH 0/3] More Coverity changes

[John Ferlan]

All the issues here are found by a later version of Coverity than
the one used by our internal testing. Two were false positives and
one just an ordering issue with the virCheckFlags in the zfs backend.

The future coverity really has a problem with strtok_r usage after a
VIR_STRDUP which only checks < 0 because it's perfectly fine for the
"source" to be NULL and a < 0 check won't fail. The reason why this is
a problem is the target is then NULL and used for the strtok_r call.
Code inspection finds the cases we have are all false positives; however,
rather than making the <= or sa_assert() type check to validate that -
I chose to use the virStringSplitCount in order to split and inspect
the input string. It was much cleaner at least on the inspection front.

The storage changes related to checking (ret == -1) resulted in a
RESOURCE_LEAK false positive.  As it turns out, the only reason why
-1 was being check was to determine whether or not the VIR_APPEND_ELEMENT
insertion failed. If that succeeds, then 'vol' is cleared anyway, so
truly we only need to attempt the free if we have a new vol. The
virStorageVolDefFree will quietly return if vol == NULL.

John Ferlan (3):
  openvz: Use virStringSplitCount instead of strtok_r
  zfs: Resolve RESOURCE_LEAK
  storage: No need to check ret after VIR_APPEND_ELEMENT

 src/openvz/openvz_conf.c              | 32 +++++++++++---------------------
 src/storage/storage_backend_logical.c |  2 +-
 src/storage/storage_backend_zfs.c     |  6 ++++--
 3 files changed, 16 insertions(+), 24 deletions(-)

-- 
2.5.0