Elements of ridpointers[] inappropriately tested for equality

Matthew Hiller hiller@redhat.com
Fri Nov 17 15:48:00 GMT 2000


	For C, C++, and Objective C, leastaways, ridpointers is
initialized as follows:

  ridpointers = (tree *) xcalloc ((int) RID_MAX, sizeof (tree));
  for (i = 0; i < N_reswords; i++)
    {
      /* If a keyword is disabled, do not enter it into the table
         and so create a canonical spelling that isn't a keyword.  */
      if (reswords[i].disable & mask)
        continue;

      id = get_identifier (reswords[i].word);
      C_RID_CODE (id) = reswords[i].rid;
      ridpointers [(int) reswords[i].rid] = id;

	...
    }

	reswords is set up such that different keywords can correspond to
the same RID_CODE. (There are elements for "__volatile", "__volatile__",
and "volatile", for example). get_identifier won't find "__volatile" when
searching for "__volatile__", however, and will in turn invoke make_node
for the new keyword, and return a different value as id. This new id will
then replace the old one in ridpointers [(int) reswords[i].rid].

	This in itself is a problem only if existing trees are compared to
values in ridpointers. Alas, this happens a lot. In c-parse.in, for
example:

       | ASM_KEYWORD maybe_type_qual '(' expr ':' asm_operands ')' ';'
                { stmt_count++;
                  c_expand_asm_operands ($4, $6, NULL_TREE, NULL_TREE,
                                         $2 == ridpointers[(int)RID_VOLATILE],
                                         input_filename, lineno); }

	$2 == ridpointers[(int)RID_VOLATILE] will come out as 1 if if
maybe_type_qual came from a "volatile" in the source code, but not a
"__volatile".

	The source tree seems to be fairly shot through with uses of
ridpointers like what I've shown above. A fix that works for the code
shown above is changing the fourth line of it to

					 C_RID_CODE ($2) == RID_VOLATILE,

but I don't know how general a solution this is, and it could be hard to
ferret out every place where this needs fixing. Should I proceed with that
course of action, or does anyone have other suggestions?

Matt Hiller



More information about the Gcc-bugs mailing list