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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Sun, 2015-11-29 at 09:54 +0000, Paul Durrant wrote:
> > -----Original Message-----
> [snip]
> > > 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.
> > 
> > It would be nice to at least be able to use the same header files, for
> > ease of porting userspace software.
> > 
> 
> It's possible that libvchan on Windows will make use of the tools/libs
> headers. As Andy says it would ease porting client software.
> 
> > In this case, VLAs are just being used as an aid for the compiler to
> > spot errors.ÂÂIt doesn't change the API/ABI, and could be #ifdef'd
> > around, if we care both for using C99 in general, and Windows support.
> > 
> 
> We still compile with VS2012 in Citrix and Xen Project uses VS2013 so we
> can't rely on C99. A #ifdef here does seem like the best solution.

Would you expect new projects (i.e. stuff based on tools/libs) to continue
to have requirements to build with those older versions? (Although with
Andy's link saying even VS2015 doesn't do VLAs maybe it is a bit moot).

I don't think using VLA here is worth an ifdef, but I think it is worth
reordering the arguments such that once we end up with a new enough
compiler baseline (in $donkeys years) we can switch without changing the
ABI (I think that's the case).

Ian.


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