This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] -Wid-clash-LEN broken
[I've cc-ed the list again]
Mark Mitchell wrote:-
> I know we talked about getting rid of maybe_get_identifier, but in the
> meantime, shouldn't maybe_get_identifier actually return NULL if there
> is an entry but it's not reall a TREE_IDENTIFIER?
That cannot happen - even in the code in CVS. If something is in the
hashtable, it *is* a TREE_IDENTIFIER. Otherwise it's a NULL pointer.
That is the reason for the cleanup part of the patch - the artificial
distinction with ERROR_MARK was introduced by my early patches, before
I realised that maybe_get_identifier was odd, and in all the revisions
we went through I stopped setting ERROR_MARK but never fully removed
code that tested for ERROR_MARK.
maybe_get_identifier() is meaningless for the C front ends - even
under the old CVS code of a week ago - since whether it returned a
node or NULL could be changed in the C code you were compiling just by
changing parameter names in function prototypes, for example. So
1) making decisions in the C compilers based upon the return value
of maybe_get_identifier is a bug. Indeed, I'd even say using
the function at all in the C front ends is a bug. Or
2) Zack's stringpool.c patch of about 6 months ago changed existing
behaviour. I have no idea if this is the case. But it is telling
that there have been no complaints during those 6 months.
However, I don't understand dwarf2asm.c, varasm.c and Java well enough
to say for them: it *may* be meaningful there (e.g. if the identifiers
it handles are not lexically valid in C code); someone else needs to
call that one.