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

[Paul Eggert]

Richard Lloyd <address@hidden> writes:

> I suspect this wasn't picked up earlier because the accept()
> function prototype requires the inclusion of <sys/socket.h>, which
> isn't #include'd in the bison source tree from what I can see.

If it isn't included, then it shouldn't be a problem, right?  Let's
wait until someone runs into a real problem before worrying about
this.  There are lots of system headers that declare a lot of
identifiers, but we shouldn't have to worry about clashes unless we
actually include the headers.


> P.S. I'm disappointed that, even after running the bison 1.875 source through
>      ansi2knr, you can't (easily) compile bison any more with a K&R C
>      compiler.

We weren't delighted to drop K&R support either, but it was turning
into too much hassle.  Part of the problem was that nobody was using
K&R any more, so the support wasn't being tested and was indubitably
buggy.

Code _generated_ by Bison should still work with K&R compilers, if
that's any consolation.

>      This could hit Solaris and HP-UX users particularly because
>      the default C compiler is K&R

HP C has supported ANSI mode since HP-UX 9.0 (released 1993), and has
defaulted to ANSI mode since HP-UX 10.30 (released in 1997).  Solaris
hasn't had a default C compiler since Solaris 1.1.2 (released 1994).
So this isn't a real problem for current or recent systems; it's a
problem only for decade-old or older systems, where people rarely run
Bison.  If there are still some people using such systems in a
computer museum or suchlike, they can easily bootstrap first by
building GCC itself (which does not require Bison or Flex to build).