scan-admin@xxxxxxxxxxxx writes ("New Defects reported by Coverity Scan for
XenProject"):
Please find the latest report on new defect(s) introduced to XenProject found
with Coverity Scan.
...
** CID 1242320: Uninitialized scalar variable (UNINIT)
/tools/libxl/libxl.c: 859 in libxl_domain_remus_start()
This is a failure to set rc on some of the error paths. It is not a
big problem, but it is a bug which should be fixed, in
libxl_domain_remus_start.
Yang Hongyang, could you prepare a patch to fix all the error exit
paths from this function to correctly set rc ? Thanks.
Then there are also a lot like this:
** CID 1242321: Unused value (UNUSED_VALUE)
/tools/libxl/libxl_remus_device.c: 216 in all_devices_setup_cb()
These are all:
Pointer "gc" returned by "libxl__ao_inprogress_gc(ao)" is never used.
This is because a lot of functions were introduced which say
STATE_AO_GC(something)
but do not happen to use the gc. This is actually perfectly normal
in libxl. And the STATE_AO_GC macro says:
libxl__gc *const gc __attribute__((unused)) = libxl__ao_inprogress_gc(ao)
So I think this is some kind of failure by Coverity.
Weirdly, although many of these uses (eg, all_devices_setup_cb at
libxl_remus_device.c:212) are in functions which do not use the
defined `ao' variable either, and ao is _not_ marked ok-to-be-unused,
Coverity hasn't complained about that.
Andrew Cooper, as our Coverity modelling expert, can you comment ?
I don't think there is actually anything wrong with having STATE_AO_GC
used when not needed. It will reduce noise in future if code is added
which needs it, and in the meantime it's harmless. So I think it
would probably be better if STATE_AO_GC declared ao
__attribute__((unused)) as well.
Yang Hongyang, supposing my comaintainers agree, would you care to
write a patch to do this ?
