Enums, bitfields and wl_arrays

[Pekka Paalanen]

On Fri, 02 Oct 2015 15:49:15 +0200
Victor Berger <victor.berger at m4x.org> wrote:

> Le 2015-10-02 15:16, Pekka Paalanen a écrit :
> > On Fri, 2 Oct 2015 13:50:42 +0100
> > Auke Booij <auke at tulcod.com> wrote:
> >> 
> >> [start]
> >> The enum and bitfield attributes are in principle for documentation
> >> purposes only. The enum and bitfield attributes may also be used by
> >> bindings, but only in such a way that code written prior to the
> >> specification of these attributes still works after their
> >> specification. In other words, specifying an attribute for an
> >> argument, that previously did not have it, should not break API.
> >> [end]
> > 
> > I like this very much. Let's see if anyone disagrees.
> > 
> > Do you intend to allow also changing rather than only adding these new
> > attributes in the wording above?
> 
> While I don't disagree, I have a small concern:
> 
> Do we agree that this involves at some point writing a specification of 
> the format of the XML files?

We have to write the new bits now. Writing the whole spec is not a
blocker for this, IMO.

> Because otherwise, if the XML format remains defined by the 
> implementation of the C scanner, and that these attributes are 
> explicitly defined as for documentation only and ignored by the C 
> scanner, this means the XML writers would be allowed to write any 
> garbage they want as a value for these fields.

I'd expect we'd have wayland-scanner check the linkage, that is, that
the enum exists unless it's from an interface not defined in this XML
file.

So, garbage with an interface name prefix would get through.

We could have a "strict mode" to wayland-scanner, where you need to
feed all relevant additional XML files also, and the check would be
cross-file then, erroring on all unknown links. Then we'd just change
our builds to use this mode.

> As a consequence, bindings writers cannot give any value to these 
> fields, and they become basically useless. I mean, it seems logical that 
> the value of the "enum" field should be something like "enum_name" or 
> "interface_name.enum_name", or whatever format will be chosen. But these 
> fields have practically no value if we cannot expect this format to be 
> respected (documentation-only fields can also simply be written in the 
> "description" field, if they are not used anywhere).

Haha. :-)

I think this was in my early objections to the whole idea of adding
these attributes in the first place. You'd only know you screwed up by
generating docs and seeing the reference links don't work.

Having the whole XML language specced out wouldn't fix this, because it
would still need a human to review the XML.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151002/463fd198/attachment.sig>