The Coverity static analyzer was generating many false positives for the
unary operation inside the VIR_FREE() definition as it was trying to evaluate
the else portion of the "?:" even though the if portion was (1).
Signed-off-by: NEric Blake <eblake@redhat.com>

The count of vCPUs for a domain is extracted as a usingned long variable
but is stored in a unsigned short. If the actual number was too large,
a faulty number was stored.

The 'msg' free is handled via virNetMessageFree() already.

It was possible to call VIR_FREE in cleanup prior to initialization

It was possible to call VIR_FREE in cleanup prior to initialization

It was possible to call VIR_FREE in cleanup prior to initialization.

It was possible to call VIR_FREE in cleanup prior to initialization

It was possible to call VIR_FREE in cleanup prior to initialization.

It was possible to call VIR_FREE in cleanup prior to initialization

It was possible to call VIR_FREE in error prior to initialization

Resolve a couple of instances where variables were not initialized
prior to potential VIR_FREE call in cleanup path.

If there was more than one inotify_event found in the read/while loop,
then only the last event found would have been queued.

The local redefinition of PED_PARTITION_PROTECTED results in the error
but is not a problem especially if the built code doesn't have the latest
definitions.

On error, the 'tapfd' in networkStartNetworkVirtual() is synonymous
with 'macTapIfName' and will be closed in the appropriate error path.

Upon successful return of virNetClientStreamEventAddCallback() the
allocated cbdata field will be freed by virNetClientStreamEventRemoveCallback()
as cbOpaque using the free function remoteStreamCallbackFree().

This avoids "Event negative_returns: A negative constant "-1" is passed as
an argument to a parameter that cannot be negative.".  The called function
uses -1 to determine whether it needs to traverse all the hostdevs.

Coverity misses the nuance of VIR_FREE(privkey) setting privkey = NULL when
if (!(virFileExists(privkey))) is true and thus declares the code dead.

The old cpu bitmap setting algorithm causes a couple of complaints which
have been tagged.

The use of switch statements inside a bounded for loop resulted in some
false positives regarding the "default:" label which cannot be reached
since each of the other case statements use the possible for loop values.
A [dead_error_begin] was added before the default label.

Commit id ebdbe25a adjusted the algorithm and the caller guarantees that
the 'params' will have a '_' in the name being searched. Add the [returned_null]
tag to the two instances.

The use of switch statements inside a bounded for loop resulted in some
false positives regarding the "default:" label which cannot be reached
since each of the other case statements use the possible for loop values.

The various _for_i loops with both u.s.car and u.s.cdr were being reported
as COPY_PASTE errors by Coverity.  This just quiets those messages.

Commit id a994ef2d changed the mechanism to store/update the default
security label from using disk->seclabels[0] to allocating one on the
fly. That change allocated the label, but never saved it.  This patch
will save the label. The new virDomainDiskDefAddSecurityLabelDef() is
a copy of the virDomainDefAddSecurityLabelDef().

The code is not reachable as of commit id: bb85f229. Removed
virKeepAliveStop() and virObjectUnref() because 'ka' cannot be
anything but NULL at the cleanup label.

Forbid the names to match the loading procedure of snapshots.

Currently, whenever somebody calls saferead() on nonblocking FD
(safewrite() is totally interchangeable for purpose of this message)
he might get wrong return value. For instance, in the first iteration
some data is read. The number of bytes read is stored into local
variable 'nread'. However, in next iterations we can get -1 from
read() with errno == EAGAIN, in which case the -1 is returned despite
fact some data has already been read. So the caller gets confused.
Bare read() should be used for nonblocking FD.

The snapshot name is used to create path to the definition save file.
When the name contains slashes the creation of the file fails. Reject
such names.

When the snapshot definition can't be saved, the
qemuDomainSnapshotCreate function succeeded without filling some of the
fields in the internal definition.

This patch removes the snapshot and returns failure if the XML file
cannot be written.

We are already logging other arguments passed, however, @flags
were missing there.

When running virDomainDestroy, we need to make sure that no other
background thread cleans up the domain while we're doing our work.
This can happen if we release the domain object while in the
middle of work, because the monitor might detect EOF in this window.
For this reason we have a 'beingDestroyed' flag to stop the monitor
from doing its normal cleanup. Unfortunately this flag was only
being used to protect qemuDomainBeginJob, and not qemuProcessKill

This left open a race condition where either libvirtd could crash,
or alternatively report bogus error messages about the domain already
having been destroyed to the caller
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The function is just a renamed public version of former
virTypedParameterArrayClear.

Working with virTypedParameters in clients written in C is ugly and
requires all clients to duplicate the same code. This set of APIs makes
this code for manipulating with virTypedParameters integral part of
libvirt so that all clients may benefit from it.

When virStorageBackendLogicalCreateVol() creates a snapshot for a
logical volume with backingStore element, it fails with the message
below:

  2013-01-17 03:10:18.869+0000: 1967: error : virCommandWait:2345 :
  internal error Child process (/sbin/lvcreate --name lvm-snapshot -L 51200K
  -s=/dev/lvm-pool/lvm-volume) unexpected exit status 3: /sbin/lvcreate:
  invalid option -- '='  Error during parsing of command line.

This is because virCommandAddArgPair() uses '=' to connect the two
parameters, it's unsuitable for -s option of the lvcreate.
Signed-off-by: NAtsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>

A build on FreeBSD failed with:
util/virportallocator.c:108: error: storage size of 'addr' isn't known
util/virportallocator.c:123: error: 'INADDR_ANY' undeclared (first use in this function)

It turns out that while POSIX allows sockaddr_in to leak in through
<arpa/inet.h> (the way Linux does it), it is not mandatory, and
conforming applications are required to get it through <netinet/in.h>.

* src/util/virportallocator.c: Include header for struct
sockaddr_in.
* tests/virportallocatortest.c: Likewise.

The fetch of 'ipdef' in networkRefreshDhcpDaemon() when the loop to fill
in ipv4def fails to find an ipv4 address with dhcp defined. The filled in
ipdef value was not used.  Code was made unnecessary with commit it 2d5cd1.