Re: [RFC] -Wid-clash-LEN broken

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

[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
either

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.

Neil.