Pre-Glib era which used malloc allowed the size of the client-side
buffers to be declared as 0, because malloc documents that it can either
return 0 or a unique pointer on 0 size allocations.
With glib this doesn't work anymore, because glib documents that for
such allocation requests NULL is always returned which results in an
error in our public API checks server-side.
This patch complements the fix in the RPC layer by explicitly erroring
out on the following combination of args used by our legacy APIs (their
moder equivalents don't suffer from this):
function(caller-allocated-array, size, ...) {
if (!caller-allocated-array && size > 0)
return error;
}
treating everything else as a valid input and potentially let that fail
on the server-side rather than client-side.
https://bugzilla.redhat.com/show_bug.cgi?id=1772842
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We copy-and-paste a lot of our docs, as evidenced by the number of
*GetXMLDesc() functions which had the same unusual indentation and
missing capital in the second sentence of the returns paragraph.
Signed-off-by: Eric Blake <eblake@redhat.com>
Whenever we declare a new object the first member of the struct
has to be virObject (or any other member of that family). Now, up
until now we did not care about the name of the struct member.
But lets unify it so that we can do some checks at compile time
later.
The unified name is 'parent'.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Seeing a log message saying 'flags=93' is ambiguous & confusing unless
you happen to know that libvirt always prints flags as hex. Change our
debug messages so that they always add a '0x' prefix when printing flags,
and '0' prefix when printing mode. A few other misc places gain a '0x'
prefix in error messages too.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The API docs for the various vir$OBJECTGetConnect functions
contain a warning
WARNING: When writing libvirt bindings in other languages, do
not use this function. Instead, store the connection and
the domain object together.
There is no reason why language bindings should not use this
method, and indeed the Perl, Python, and Go bindings all use
these methods.
This warning was originally added back in
commit 3edb4bc9fb
Author: Daniel Veillard <veillard@redhat.com>
Date: Tue Jul 24 15:32:55 2007 +0000
* libvirt.spec.in NEWS docs/* po/*: preparing release 0.3.1
* src/libvirt.c python/generator.py: some cleanup and warnings
from Richard W.M. Jones
IIUC, the rational was that these APIs do not need to be
directly exposed to the non-C language, as the language
can expose the same concept itself by storing the original
virConnectPtr object alongside the virDomainPtr. There's
no reason to mandate such an approach though - it is valid
for languages to expose this directly if that suits their
needs better.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
There are also a couple that were very uninformatively just logging
the value of the pointer rather than the string itself:
* the "name" arg to virNodeDeviceLookupByName()
* wwnn and wwpn args to virNodeDeviceLookupSCSIHostByWWN()
All char*'s that make sense should now have their contents logged
rather than the pointer, and all %s args should now be inside
NULLSTR().
