This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: My evil plans for the next few weekends

On Tue, 2005-05-17 at 14:59 -0400, Richard Kenner wrote:
>     The main case i've hit so far is DECL_CONTEXT, which is also
> Are there any other cases?  Offhand, I can't think of another DECL field
> that's shared by only a subset of DECLs.
An example is DECL_INITIAL vs DECL_QUALIFIER. You could theoret
There are shared *fields*, but the macros are stricter than DECL_CHECK
(IE FUNCTION_DECL_CHECK or TYPE_DECL_CHECK)  so they can't be accessed
through the wrong macro.

For example, FIELD_DECL and VAR_DECL both use bit_field_flag, for two
different purposes, but the DECL_IN_TEXT_SECTION macro checks to make
sure the node is a VAR_DECL before you can access it as a VAR_DECL, and
the DECL_BIT_FIELD macro makes sure the node is a FIELD_DECL before you
can access it on a FIELD_DECL.

Thus, there is no way we could be using that field unsafely, unless we
were doing it bare (ie tree->decl.bit_field_flag)

I audited the other ones for FIELD_DECL, and most of the "unsafe" macros
(IE just doing DECL_CHECK) are only used in one or two source files, and
looking at the context makes it clear they won't be called on FIELD_DECL
in those cases (IE they are inside if (code == FUNCTION_DECL) or

The only ones that appear in more than a few places are DECL_REGISTER vs


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]