Re: [Qemu-devel] [PATCH 3/5] qapi: avoid reserved word restrict

[Michael Roth <mdroth@linux.vnet.ibm.com>]

On Tue, Jul 31, 2012 at 04:56:50PM +0000, Blue Swirl wrote:
> On Tue, Jul 31, 2012 at 12:58 PM, Luiz Capitulino
> <lcapitulino@redhat.com> wrote:
> > On Tue, 31 Jul 2012 09:28:43 +0200
> > Paolo Bonzini <pbonzini@redhat.com> wrote:
> >
> >> Il 30/07/2012 18:04, blauwirbel@gmail.com ha scritto:
> >> > From: Blue Swirl <blauwirbel@gmail.com>
> >> >
> >> > Clang compiler complained about use of reserved word 'restrict' in SLIRP
> >> > and QAPI.
> >> >
> >> > Rename 'restrict' to 'restricted' which also matches other SLIRP code.
> >>
> >> Can't do it, this changes the command-line option.
> >>
> >> Luiz, Michael, any ideas?
> >
> > I'm not sure how complicated it would be to implement this, but we could add
> > a 'bind' keyword to the type dict to control mapping between protocol names
> > and generated variable names. Like this:
> >
> > { 'type': 'NetdevUserOptions',
> >   'data': {
> >     '*hostname':  'str',
> >     '*restrict':  'bool',
> >     ...
> >     '*hostfwd':   ['String'],
> >     '*guestfwd':  ['String'] },
> >
> >   'bind': { 'restrict': 'restricted' } }
> 
> How about prefixing all json-generated field names with for example
> 'json_'? Should be a simple mechanical change.

It's a whole lot of churn though, and clobbers the history for most QMP
functions. It also seems like a strange thing for clang to complain about...

I think special casing is probably the way to go...

Luiz's bind approach seems reasonable, though "alias" might be the more
familiar name.

As an alternative I'll throw out there, the QIDL series introduces the
notion of "annotated" fields, which allow us to pass additional
information to the code generators (instead of just the typename)
regarding how to handle that field internally. So we could do something like:

{ 'type': 'NetdevUserOptions',
  'data': {
    '*hostname':  'str',
    '*restrict': {
      '<annotated>': 'true',
      'type': 'bool',
      'native_name': 'restrict' },
    ... 
    '*hostfwd':   ['String'],
    '*guestfwd':  ['String'] } }

It's pretty flexible, but I'm hesitant to expose in documented schemas.

> 
> In addition to 'restrict', there may also be problems with 'if'
> (-drive, HMP drive_add) and maybe also 'auto' as value (several
> command line options, HMP pci_add) in the future.
>