<div dir="ltr"><div>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?<br>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 3, 2014 at 1:09 PM, Nils Chr. Brause <span dir="ltr"><<a href="mailto:nilschrbrause@gmail.com" target="_blank">nilschrbrause@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>I see.<br><br></div>In that case, I'll have to maintain my own xml file for my C++ bindings. <br>
<br></div>Thanks,<br></div>Nils<br><br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Sep 3, 2014 at 10:20 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div>On Wed, 3 Sep 2014 10:28:30 +0300<br>
Giulio Camuffo <<a href="mailto:giuliocamuffo@gmail.com" target="_blank">giuliocamuffo@gmail.com</a>> wrote:<br>
<br>
> 2014-09-03 10:15 GMT+03:00 Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>>:<br>
> > On Mon, 1 Sep 2014 22:07:44 +0200<br>
> > "Nils Chr. Brause" <<a href="mailto:nilschrbrause@gmail.com" target="_blank">nilschrbrause@gmail.com</a>> wrote:<br>
> ><br>
> >> On Mon, Sep 1, 2014 at 10:45 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote:<br>
> ><br>
> >> > Another problem with this patch is that while it adds new syntax to the<br>
> >> > protocol XML, it does not add anything that would either explain nor<br>
> >> > validate/enforce it. (We do not actually use the DTD for anything<br>
> >> > anymore.)<br>
> >> ><br>
> >> > Yes, we do not have a document describing the XML format, and that is a<br>
> >> > problem. Would be nice to start one, if anyone can work with Publican.<br>
> >> ><br>
> >> > The very least, wayland-scanner should be reading the enum attribute<br>
> >> > and check that the referenced enum exists. I'm not sure if it can<br>
> >> > generate a nice doc snippet into the generated code, but if there is a<br>
> >> > way to include that, it would be useful. We need *something* in the<br>
> >> > Wayland repository actually using these new attributes, so that they do<br>
> >> > not bit-rot immediately.<br>
> >><br>
> >> I will look into the scanner code then. That is probably the easiest<br>
> >> possibility<br>
> >> to prevent bit-rot, since I never did anything with Publican.<br>
> >><br>
> >> While I'm at that, I would also like to make use of the enum names in the<br>
> >> generated C code. As far as I can see, this would not break any existing<br>
> >> code, would it? Also, that would require the enum definitions to be at the<br>
> >> top<br>
> >> of the header files (just below the struct forward declarations), because<br>
> >> enums cannot be forward declared. Would that be acceptable?<br>
> ><br>
> > Perhaps, if it does not cause problems on C++. I'm not sure, but I<br>
> > recall C++ being more strict than C wrt. enums.<br>
><br>
> It is, in the sense that it doesn't automatically cast int to enums,<br>
> so that could break the API. Also, wouldn't it possibily be an ABI<br>
> break? Afaik enums don't have a very defined size, so what is now a<br>
> int32 could become e.g. a 16 bits enum field.<br>
<br>
</div></div>Yeah, I think that is another valid concern.<br>
<br>
<br>
Thanks,<br>
pq<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>