On Tue, Jun 2, 2009 at 8:43 PM, Samuel Bronson <naesten@xxxxxxxxx> wrote: > Hmm, which tree is yours? I pulled from > git://git.kernel.org/pub/scm/devel/sparse/sparse.git I have a development tree for sparse at: http://git.kernel.org/?p=devel/sparse/chrisl/sparse.git;a=summary > As for the bit operations, those are perfectly legal for enum values, > and there are two similar enum types defined in this very header: But they are simple assign, they don't have the following + MOD_NONLOCAL = (MOD_EXTERN | MOD_TOPLEVEL), + MOD_STORAGE = (MOD_AUTO | MOD_REGISTER | MOD_STATIC | MOD_EXTERN | MOD_INLINE | MOD_TOPLEVEL | MOD_FORCE), + MOD_SIGNEDNESS = (MOD_SIGNED | MOD_UNSIGNED | MOD_EXPLICITLY_SIGNED), + MOD_SPECIFIER = (MOD_CHAR | MOD_SHORT | MOD_LONG | MOD_LONGLONG | MOD_SIGNEDNESS), + MOD_SIZE = (MOD_CHAR | MOD_SHORT | MOD_LONG | MOD_LONGLONG), + MOD_IGNORE = (MOD_TOPLEVEL | MOD_STORAGE | MOD_ADDRESSABLE | + MOD_ASSIGNED | MOD_USERTYPE | MOD_ACCESSED | MOD_EXPLICITLY_SIGNED), + MOD_PTRINHERIT = (MOD_VOLATILE | MOD_CONST | MOD_NODEREF | MOD_STORAGE) Same can apply to pretty much all constant defines. It doesn't mean that we should replace all constant defines into enum. There is no actual benefit for people who runs sparse. >> Changing bitfield from "char" to "int" has risk of making the symbol >> struct bigger. We don't want that because symbol is a very common >> structure for sparse. > > When could this actually happen? Here (on i386), pahole says this: You answer yourself, it is implementation defined. Most of the people just run sparse. They don't benefit from your change. Personally I think how gdb print them is not a big deal. No worth to risk it. Chris -- 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
