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