Re: [Xen-devel] [PATCH XEN v5 13/23] tools: Refactor foreign memory mapping into libxenforeignmemory

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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