[PATCH wayland] Add "enum" attribute to "arg" elements

[Nils Chr. Brause]

On Wed, Sep 3, 2014 at 9:15 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Mon, 1 Sep 2014 22:07:44 +0200
> "Nils Chr. Brause" <nilschrbrause at gmail.com> wrote:
> >
> > While I'm at that, I would also like to make use of the enum names in the
> > generated C code. As far as I can see, this would not break any existing
> > code, would it? Also, that would require the enum definitions to be at the
> > top
> > of the header files (just below the struct forward declarations), because
> > enums cannot be forward declared. Would that be acceptable?
>
> Perhaps, if it does not cause problems on C++. I'm not sure, but I
> recall C++ being more strict than C wrt. enums.
>
> I do not believe we can change the XML format so that some <enum>
> elements would become <bitfield> instead. Existing generators would
> probably ignore <bitfield> and we need to keep the XML format stable.
>
> Considering all that, I'm not really sure that supporting strictly
> typed languages is worth the effort. After all, this API is for toolkit
> developers, and app developers will be using toolkit APIs, not this.

Well, there are still plenty of people using low-level libx11/xcb instead of
higher-level toolkits. Even on non-C languages. If they move to Wayland,
they probably won't suddenly change their mind. ;)


On Wed, Sep 3, 2014 at 3:44 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Wed, 3 Sep 2014 15:03:55 +0200
> "Nils Chr. Brause" <nilschrbrause at gmail.com> wrote:
>
> > Another possibility would of course be to add an 'is_bitfield="true"'
> > attribute to enum elements that are actually bit fields instead of using
> > 'bitfield' elements. Every sanely written scanner should be able to cope
> > with that, shouldn't it?
>
> I believe so, yes.
>
> Btw. the enum size issue could bite you years from now, if you use enum
> in a public library API. If the enum happens to be 16-bit now, then
> someone adds a value that does not fit in 16 bits and the enum grows
> implicitly to 32 bits, that will break your library ABI in a very
> surprising way. That someone may not even know about your library, as
> he might be editing just some XML file in another project.
>
> If you can force enums to be always (at least these particular enums)
> 32 bits, you should be safe even when using them in public API. I'm
> still not sure how good idea that is, though.

Yes, using scoped enums, you can the the size. :)


A new patch will follow in a few minutes.


Thanks,
Nils