Le mercredi 11 avril 2012 22:53:23 Mauro Carvalho Chehab, vous avez écrit : > > But you have been royally ignoring that rule when it > > comes to extending existing enumerations: > The existing enumerations can be extended, by adding new values for unused > values, otherwise API functionality can't be extended. Yes. That's why they should be some unsigned type. > Yet, except > for a gcc bug (or weird optimize option), I fail to see why this would > break the ABI. >From the perspective of the compiler, this is a feature not a bug. In C and C++, loading or storing a value in an enumerated variable whereby the value is not a member of the enumeration is undefined. In other words, the compiler can assume that this does not happen, and optimize it away. > If this is all about some gcc optimization with newer gcc versions, then > maybe the solution may be to add some pragmas at the code to disable such > optimization when compiling the structs with enum's at videodev2.h. Maybe the Linux kernel could be specifically compiled to prevent GCC from range-optimizing enumerations. But as -fno-jump-table only disables one of several potential range optimizations, I doubt this is even possible. Regardless, you cannot require all of Linux userspace to rely on an hypothetic non-standard GNU C extension. Thus extending enums remains a silent userspace ABI break in any case. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
