On Mon, 27 Apr 2015 14:20:09 +0200 Auke Booij <[email protected]> wrote:
> On 21 Apr 2015 09:18, "Pekka Paalanen" <[email protected]> wrote: > > Two things I came up with in the IRC discussion was that only <arg> > > types of int an uint are eligible for enums, and only uint for > > bitfields. I think wayland-scanner should enforce that. > > I just realised another aspect of this. Can a (non-bitfield) enum be used > both as an int and a uint? So some *int* argument somewhere has enum="bla", > and a *uint* argument somewhere else has enum="bla" as well. What about > enums that list negative values, can they be used as uints? > > I feel that this would be extremely prone to bugs, and in fact I think this > is a situation where semantic information of enum style arguments can help > catch bugs in C code (which so far we haven't seen yet in this debate). > > Should this be enforced by the scanner? Or is there some crazy situation in > which it makes sense? I can't think of anything where using int in one place and uint in another place for the same enum set would be sensible. It's a similar convention to always using uint for bitfields. An enum with negative values vs. uint is obviously a bug, except maybe for the -1 shorthand for all bits set. However, these are spec bugs. If we find them in interfaces that are already stable... maybe they could be fixed, C shouldn't care. Would be hard for strictly typed languages, again. These could be warnings from wayland-scanner. Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
