Name Conflict With Multiple Parsers In Same Program

I'm trying to use two parsers in the same program to parse different
grammars.  The %name-prefix declaration works fine for as far as it goes.

However, I'm also using

     #define YYDEBUG 1
     %pure-parser
     %lex-param {LPPLLOCALVARS lpplLocalVars}
     %parse-param {LPPLLOCALVARS lpplLocalVars}

as well as function prototypes which complicates the picture.

Each source file (including the .c files generated from the .y files) 
has its own separate file with an extension of .pro which consists of
the compiler's output from generating the source file's prototypes.
For example, one of the generated .pro files has an entry for

extern int __cdecl fh_yyparse(void );

while the other has

extern int __cdecl pl_yyparse(void );

corresponding to %name-prefix="fh_yy" and %name-prefix="pl_yy"
respectively in the two source files.  All of the prototype files are
#included in one header file and that file is #included in every
source file (with appropriate #ifdefs around it for when the
prototypes are being generated).

Thus, there is a file called "compro.h" which has a line for each

parser does not work under cygwin

Hi

On my machine the generated parser does not work properly. The yyparse() 
method returns 1 any time. I am working on Windows XP SP2 with the 
current Cygwin release.
bye,
Falk S.

Version report:
bison 2.3
gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)

Attachments:
simple.y yacc input file
simple.c generated output file by bison (with -t -v -o)
simple.output see above

/* A Bison parser, made by GNU Bison 2.3.  */

/* Skeleton implementation for Bison's Yacc-like parsers in C

   Copyright (C) 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004, 2005, 2006
   Free Software Foundation, Inc.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2, or (at your option)
   any later version.

Re: Name Conflict With Multiple Parsers In Same Program

Do I understand you correctly in saying that you're trying to do a
single C compilation that #includes two different Bison-generated .c
files?  That would explain the problem: Bison doesn't support that,
and is designed only for separate compilation.

Is there some reason you can't use separate compilation?

Re: Name Conflict With Multiple Parsers In Same Program

On 13 Jun 2007, at 19:09, Paul Eggert wrote:

> Do I understand you correctly in saying that you're trying to do a
> single C compilation that #includes two different Bison-generated .c
> files?

Oops, I missed that on Help-Bison. 

> That would explain the problem: Bison doesn't support that,
> and is designed only for separate compilation.

On the other hand, if there are only four names which haven't been  
namespacified, would it be difficult to admit it?

   Hans Aberg

Re: Name Conflict With Multiple Parsers In Same Program

On 6/13/2007 5:16 PM, Hans Aberg wrote:
> On 13 Jun 2007, at 19:09, Paul Eggert wrote:
> 
>> Do I understand you correctly in saying that you're trying to do a
>> single C compilation that #includes two different Bison-generated .c
>> files?
> 
> Oops, I missed that on Help-Bison. 
> 
>> That would explain the problem: Bison doesn't support that,
>> and is designed only for separate compilation.
> 
> On the other hand, if there are only four names which haven't been 
> namespacified, would it be difficult to admit it?

The compilations are separate:  one in file <parse.c> and the other in 
file <dfnhdr.c> each generated by Bison from the respective .y files.

The #includes common to all files are the .pro files generated by the 
C compiler.  Each .pro file contains the prototypes for each function 
in the corresponding .c file.

The problem I have is that the .pro files corresponding to the two 
parser-generated .c files each contain a prototype for the four 
functions I mentioned before.  However, because of the different use 
of %lex-param in the two parser files, the prototype for (say) 
yydestruct is different in the two .pro files.

If you like, I'd be glad to generate a minimal set of files which 
reproduces the problem.

Re: Name Conflict With Multiple Parsers In Same Program

On 14 Jun 2007, at 00:38, Bob Smith wrote:

> If you like, I'd be glad to generate a minimal set of files which  
> reproduces the problem.

You wrote down the conflicting names, so it should not be difficult  
fixing them. I am not the one doing it, but I think you can wait with  
the work. 

   Hans Aberg

Re: Name Conflict With Multiple Parsers In Same Program

On 6/13/2007 5:43 PM, Hans Aberg wrote:
> On 14 Jun 2007, at 00:38, Bob Smith wrote:
> 
>> If you like, I'd be glad to generate a minimal set of files which 
>> reproduces the problem.
> 
> You wrote down the conflicting names, so it should not be difficult 
> fixing them. I am not the one doing it, but I think you can wait with 
> the work. 

OK by me.  I had thought there was some confusion in some minds about 
the nature of the problem.  It is very obscure.

I have a workaround, so whenever you guys get around to it is fine 
with me.  It's one of those nice-to-have fixes.

--

-- 
_______________________________________________________________
Bob Smith - bsmith <at> sudleyplace.com - http://www.sudleyplace.com

Re: Name Conflict With Multiple Parsers In Same Program

Bob Smith <bsmith <at> sudleyplace.com> writes:

> The #includes common to all files are the .pro files generated by the
> C compiler.  Each .pro file contains the prototypes for each function
> in the corresponding .c file.

Sorry, I don't follow.  What is the point of a .pro file containing a
prototype for a static function?  Static functions aren't visible to
any module outside the corresponding .c file.  Shouldn't static
functions always be suppressed from .pro files that you intend to
include elsewhere?

Re: Name Conflict With Multiple Parsers In Same Program

On 6/13/2007 10:42 PM, Paul Eggert wrote:
> Bob Smith <bsmith <at> sudleyplace.com> writes:
> 
>> The #includes common to all files are the .pro files generated by the
>> C compiler.  Each .pro file contains the prototypes for each function
>> in the corresponding .c file.
> 
> Sorry, I don't follow.  What is the point of a .pro file containing a
> prototype for a static function?  Static functions aren't visible to
> any module outside the corresponding .c file.  Shouldn't static
> functions always be suppressed from .pro files that you intend to
> include elsewhere?

I agree.

However, if there's a compiler switch to suppress static functions 
from the output when generating prototypes, I'm missing it.

--

-- 
_______________________________________________________________
Bob Smith - bsmith <at> sudleyplace.com - http://www.sudleyplace.com

Re: Name Conflict With Multiple Parsers In Same Program

Bob Smith <bsmith <at> sudleyplace.com> writes:

> However, if there's a compiler switch to suppress static functions
> from the output when generating prototypes, I'm missing it.

OK, thanks, I think I understand the problem now.  Since you have
a workaround and this is kind of a weird situation it's not high
priority but if someone wants to fix it that'd be fine.