[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH XEN v5 13/23] tools: Refactor foreign memory mapping into libxenforeignmemory
On Fri, 2015-11-13 at 15:27 +0000, Ian Jackson wrote: > Ian Campbell writes ("Re: [PATCH XEN v5 13/23] tools: Refactor foreign > memory mapping into libxenforeignmemory"): > > On Wed, 2015-11-11 at 15:13 +0000, Ian Jackson wrote: > > Are you suggesting: > > > > void *xenforeignmemory_map(xenforeignmemory_handle *fmem, uint32_t dom, > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂint prot, const xen_pfn_t *arr, > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂint err_out[num], > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂunsigned int num); > > > > Is that (a var sized array based on another param) really allowed? > > Yes, if the array size precedes the array. Sadly: for i in include/xenforeignmemory.h; do \ ÂÂÂÂgcc -x c -ansi -Wall -Werror -pedantic -I/local/scratch/ianc/devel/libxenctrl-split/xen.git/tools/libs/foreignmemory/../../../tools/include \ ÂÂÂÂÂÂÂÂÂÂ-S -o /dev/null $i || exit 1; \ ÂÂÂÂecho $i; \ done >headers.chk.new include/xenforeignmemory.h:142:28: error: ISO C90 forbids variable length array âarrâ [-Werror=vla] ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂconst xen_pfn_t *arr[pages], int err[pages]); ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ^ include/xenforeignmemory.h:142:28: error: ISO C90 forbids variable length array âerrâ [-Werror=vla] cc1: all warnings being treated as errors /local/scratch/ianc/devel/libxenctrl-split/xen.git/tools/libs/foreignmemory/../../../tools/Rules.mk:200: recipe for target 'headers.chk' failed It's -ansi (AKA -std=c90) together with -pedantic which does it. -std=c99 is happy with it (including with -pedantic). The original motivation for this check was [0]: As part of the tidyup, we should choose a particular C standard (89, probably) and ensure that the API/ABI complies with `gcc -std=c$VER -pedantic`.ÂÂThis will help to provide a consistent API on other platforms (I seem to recall an effort to port libvchan to windows.) It's not clear to me how much the "89 probably" was influenced by the "on other platforms ... windows" bit (maybe Andy or Paul has an opinion). C99 was 16 years ago now, I'm struggling to think of a reason not to move the baseline for tools stuff at least to that. https://en.wikipedia.org/wiki/Visual_C%2B%2BÂmight be one such reason I suppose, although I'm not convinced a libvchan port to Windows, even if not entirely hypothetical, would be using any of xen.git/tools/libs/* rather than the equivalent frameworks provided by the Windows PV drivers. Ian. [0]Âhttp://article.gmane.org/gmane.comp.emulators.xen.devel/247265 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |