On Fri, 1 Dec 2006, Geoff Levand wrote: > > One of the gcc maintainers (Andrew Pinski) told me to set it up that > way, so I figured it was safe. It _is_ safe, as long as you stick to gcc, and as long as you don't mix signs in your values, for example. But we actually want to let people compile even the kernel with other compilers than gcc. Most of the time, that means that we strongly encourage those compiler people to support all the gcc extensions (let's face it, standardization is good, and open standards work better than closed ones, and gcc is the most widely spread open and portable compiler BY FAR, so it would be stupid to _not_ do that). But at times, some of the gcc extensions aren't necessarily that well defined or thought out, or simply not worth it. The extended type system for enums in gcc is just basically messy, and it doesn't really offer you anything important. Compared with inline assembly, for example, inline assembly may be even messier and more complicated, but inline assembly definitely offers you something very important. The strange enum type extensions? What do they really offer above and beyond the standard C preprocessor #define's? Apart from some (very limited) name scoping advantages, there really isn't anything that it really helps with. And as Al already mentioned, some of the extensions aren't even compatible within different versions of gcc itself. Admittedly they are all fairly special, but basically the "type" of different individual enum members simply isn't well-defined in all cases, and will even depend on thigns like the order they were declared in, if I recall correctly. Messy, messy. Linus - To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
