[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: bison 1.875 variable vs. function name clash: accept
Date: 07 May 2003 12:12:15 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

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

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).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]