mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-23 21:34:54 +03:00
Libvirt native C API and daemons
0aa6eedddd
fine, except that is subtly alters the semantics of malloc(), calloc(), and realloc(). In particular, if you say: foo = malloc(0); glibc will happily return a non-NULL pointer to you. However, with the new memory management stuff, if you say: foo = VIR_ALLOC(0); you will actually get a NULL pointer back. Personally, I think this is a dangerous deviation from malloc() semantics that everyone is used to, and is indeed causing problems with the remote driver. The short of it is that the remote driver allocates memory on behalf of the remote side using VIR_ALLOC_N, and this call is returning NULL so that the NULL checks elsewhere in the code fire and return failure. The attached patch fixes this situation by removing the 0 checks from the memory allocation paths, and just lets them fall through to the normal malloc(), calloc(), or realloc() routines, restoring old semantics. Signed-off-by: Chris Lalancette <clalance@redhat.com> |
||
|---|---|---|
| build-aux | ||
| docs | ||
| gnulib | ||
| include | ||
| m4 | ||
| po | ||
| proxy | ||
| python | ||
| qemud | ||
| src | ||
| tests | ||
| .cvsignore | ||
| .x-sc_avoid_if_before_free | ||
| .x-sc_avoid_write | ||
| .x-sc_no_have_config_h | ||
| .x-sc_prohibit_strcmp | ||
| .x-sc_require_config_h | ||
| .x-sc_trailing_blank | ||
| acinclude.m4 | ||
| AUTHORS | ||
| autobuild.sh | ||
| autogen.sh | ||
| bootstrap | ||
| ChangeLog | ||
| configure.in | ||
| COPYING.LIB | ||
| GNUmakefile | ||
| HACKING | ||
| libvirt.pc.in | ||
| libvirt.spec.in | ||
| Makefile.am | ||
| Makefile.cfg | ||
| Makefile.maint | ||
| NEWS | ||
| README | ||
| RENAMES | ||
| TODO | ||
| virsh.1 | ||
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>