Enums, bitfields and wl_arrays

[Auke Booij]

On 2 October 2015 at 14:49, 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?
>
> 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.
>
> 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).
>
> --
> Victor
>

I agree with your concern. However, note that "for documentation
purposes" does not mean that it is just a documentation string: we
document a very clear and precise fact, for the purpose of
understanding the API (ie documentation). My previous patches indeed
do some checking wrt enum name cross-matching. This would have to be
extended for enum names that refer to a different interface.

Pekka's proposal to include a "strict" mode will help here, for
cross-XML-interface-checking. Even though this would be optional, it
means we'll have to let go of the idea that protocol files are mostly
independent (if there ever was any such belief).