Cygwin 'byacc' question

Andrey Tarasevich <andreytarasevich@hotmail.com>
2 Nov 2005 22:13:19 -0500

          From comp.compilers

Related articles
Cygwin 'byacc' question andreytarasevich@hotmail.com (Andrey Tarasevich) (2005-11-02)
Re: Cygwin 'byacc' question kst-u@mib.org (Keith Thompson) (2005-11-04)
Re: Cygwin 'byacc' question bill@qswtools.com (Bill Cox) (2005-11-08)
Re: Cygwin 'byacc' question toby@telegraphics.com.au (toby) (2005-11-12)
Re: Cygwin 'byacc' question andreytarasevich@hotmail.com (Andrey Tarasevich) (2005-11-12)
Re: Cygwin 'byacc' question dickey@saltmine.radix.net (Thomas Dickey) (2005-12-19)
| List of all articles for this month |

From: Andrey Tarasevich <andreytarasevich@hotmail.com>
Newsgroups: comp.compilers
Date: 2 Nov 2005 22:13:19 -0500
Organization: Posted via Supernews, http://www.supernews.com
Keywords: yacc, question
Posted-Date: 02 Nov 2005 22:13:19 EST

Hello


I'm using Berkley Yacc (byacc) generator from Cygwin package in my
project and now I'm in the process of switching to the newer version
of Cygwin. While doing this I ran into the following problem. The old
version of byacc (identifies itself as 'Berkley Yacc (+28-B19)' and
appears to be pretty ancient) declared file-scope data in the
following manner (using 'yycheck' as an example):


    static YYCONST short yycheck[] = { <whatever> };


The new version (identifies itself as 'Berkley Yacc 1.9') taking the
same input generates a .c file, which declares the same data as
follows:


    const short yycheck[] = { <whatever> };


Note that the new version no longer declares the data as 'static'. In
a project that contains several parsers this will normally result in a
"multiple definition" error for 'yycheck' array (assuming that it is
compiled with a C complier). That's the problem I ran into. Could
anyone please shed some light on this issue? Why is the new byacc
declaring such objects as having external linkage? Is this just a
matter of configuring byacc properly?


As a workaround, I can probably use a different prefix for each
parser, instead of the default 'yy', thus eliminating the name
conflict, but it is still strange to have the global namespace
polluted with essentially local names. Any ideas?


Best regards,
Andrey Tarasevich


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.