Rolland Dudemaine <[email protected]> writes: > I'm not sure what a "clever" compiled would do with a value that > doesn't belong to the enum is casted to the enum, but I would expect > it to complain that the value is not defined in the enum, resulting in > a different but nonetheless replacement warning.
Such a compiler would be wrong, in my opinion. In C (though not C++), it is perfectly legal to mix enums and ints interchangably. It *might* be reasonable for a compiler to warn if you do so without casting, but if it warns *with* the cast, it's just broken. > I'm not sure what the issue is with adding those dummy ones to the > enum. If your concern is that you cannot count the number of elements > in the enum, then maybe one entry should be added to define a _MAX > value. The issue is that pixman.h is a public header containing API that we are committed to maintain for the forseeable future. The PIXMAN_solid etc. values are internal API that shouldn't be used by users of pixman. Soren _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
