Re: bison 1.875 variable vs. function name clash: accept

[Paul Eggert]

The ChangeLog says Akim renamed that identifier from "axiom" to
"accept" on 2002-07-29; perhaps he can think of a better name if he's
so inclined.  I think it's low priority, though, for the reasons
discussed below.

Jonathan Ward <address@hidden> writes:

> The linker simply issues a warning:
> ld: Type mismatch for symbol "accept"; resolving FUNC symbol (in file 
> /usr/lib/hpux32/libc.so) to OBJECT symbol (in file symtab.o)

That should be the correct behavior, unless Bison somehow contrives to
call the "accept" function.  It can't do so directly, since it doesn't
call "accept".  I suppose it might be a problem if some standard C
function called by Bison invokes "accept" on Bison's behalf, but I
don't see how this could possibly happen, so I think we're OK.

> I have seen more than a few times where this has lead to severe
> problems, and not just on HP-UX.

Yes, in general it can lead to severe problems, and I've run into them
myself.  However, I don't see how this particular case could lead to a
problem.

There are thousands of nonstandard names that are used in C libraries
all over the world.  Bison can't reasonably be expected to avoid them
all.  We have to avoid names that cause real trouble, of course, but
that's not the case here.

> The GNU Coding standard states: 
> (http://www.ie.gnu.org/prep/standards_25.html#SEC25)
> "Don't use local variables or parameters that shadow global identifiers."

But that isn't the issue here.  Nothing is being shadowed, since
"accept" is not being declared globally in the C program.

As far as I can see, this is merely a question about whether Bison
should change itself to avoid generating a harmless warning issued by
the HP-UX linker.  Bison is clearly conforming to the C and POSIX
standards here, so if there actually a problem in executing Bison, it
would be a bug in HP-UX.