Re: Errors in compilation // xl_cmdimpl.c:2733:11 ...

[Ian Campbell <Ian.Campbell@citrix.com>]

On Fri, 2012-08-24 at 19:42 +0100, Andrew Cooper wrote:
> On 24/08/12 17:43, p.d@gmx.de wrote:
> > nice time,
> >
> > Ian, I'm not sure, but I think after Your patch:
> > http://xenbits.xen.org/hg/xen-unstable.hg/rev/4ca40e0559c3
> >
> > xen-tools (+qemu+seabios) will not be maked :)
> >
> > Here are last lines of "make -j7":
> > ==============================================================
> > gcc  -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable   -D__XEN_TOOLS__ -MMD -MF ._libxl_save_msgs_callout.o.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls  -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/usr/src/xen_2012_08_24_rev_25779/tools/libxl/../../tools/libxc -I/usr/src/xen_2012_08_24_rev_25779/tools/libxl/../../tools/include -I/usr/src/xen_2012_08_24_rev_25779/tools/libxl/../../tools/libxc -I/usr/src/xen_2012_08_24_rev_25779/tools/libxl/../../tools/include -I/usr/src/xen_2012_08_24_rev_25779/tools/libxl/../../tools/xenstore -I/usr/src/xen_2012_08_24_rev_25779/tools/libxl/../../tools/include -I/usr/src/xen_2012_08_24_rev_25779/tools/libxl/../../tools/blktap2/control -I/usr/src/xen_2012_08_24_rev_25779/tools/libxl/../../tools/blktap2/include -I/usr/src/xen_2012_08_24_rev_25779/tools/libxl/../../tools/include -include /usr/src/xen_2012_08_24_rev_25779/tools/libxl/../../tools/config.h  -c -o _libxl_save_msgs_callout.o _libxl_save_msgs_callout.c 
> > xl_cmdimpl.c: In function ‘main_list’:
> > xl_cmdimpl.c:2733:11: error: ‘hand’ may be used uninitialized in this function [-Werror=uninitialized]
> > xl_cmdimpl.c:2689:14: note: ‘hand’ was declared here
> > <snip>
> 
> Please try the attached patch.  I have fixed the error, and also
> future-proofed the logic.
> 
> @Ian: the patch can be slimed down if default_output_format can be
> guaranteed not to change across the duration of this function call, but
> my cursory glance at this otherwise-unfamilar codebase cant say for certain.

It can only change during argument parsing.

gcc is being a bit dumb here since default_output_format is a statically
initialised enum whose only values are OUTPUT_FORMAT_JSON and
OUTPUT_FORMAT_SXP.

I suspect that now you have re-written it so that hand is only touched
iff format == JSON and format is const that initialisation of hand is no
longer necessary. But nonetheless:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel