[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |