mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-02-10 21:51:31 +00:00
0208face59
There are several functions that call virNetlinkCommand, and they all follow a common pattern, with three exit labels: err_exit (or cleanup), malformed_resp, and buffer_too_small. All three of these labels do their own cleanup and have their own return. However, the malformed_resp label usually frees the same items as the cleanup/err_exit label, and the buffer_too_small label just doesn't free recvbuf (because it's known to always be NULL at the time we goto buffer_too_small. In order to simplify and standardize the code, I've made the following changes to all of these functions: 1) err_exit is replaced with the more libvirt-ish "cleanup", which makes sense because in all cases this code is also executed in the case of success, so labelling it err_exit may be confusing. 2) rc is initialized to -1, and set to 0 just before the cleanup label. Any code that currently sets rc = -1 is made to instead goto cleanup. 3) malformed_resp and buffer_too_small just log their error and goto cleanup. This gives us a single return path, and a single place to free up resources. 4) In one instance, rather then logging an error immediately, a char* msg was pointed to an error string, then goto cleanup (and cleanup would log an error if msg != NULL). It takes no more lines of code to just log the message as we encounter it. This patch should have 0 functional effects.
LibVirt : simple API for virtualization
Libvirt is a C toolkit to interact with the virtualization capabilities
of recent versions of Linux (and other OSes). It is free software
available under the GNU Lesser General Public License. Virtualization of
the Linux Operating System means the ability to run multiple instances of
Operating Systems concurrently on a single hardware system where the basic
resources are driven by a Linux instance. The library aim at providing
long term stable C API initially for the Xen paravirtualization but
should be able to integrate other virtualization mechanisms if needed.
Daniel Veillard <veillard@redhat.com>