[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Errors in compilation // xl_cmdimpl.c:2733:11 ...



On Fri, 2012-08-24 at 19:42 +0100, Andrew Cooper wrote:
> On 24/08/12 17:43, p.d@xxxxxx 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@xxxxxxxxxx>

Ian.


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.