Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cs.columbia.edu!leland
From: leland@cs
Newsgroups: comp.lang.c
Subject: two (or more) lex's/yacc's in one executable
Message-ID: <1990Dec6.200944.13037@cs.columbia.edu>
Date: 6 Dec 90 20:09:44 GMT
Sender: leland@cs.columbia.edu (Lee Woodbury)
Reply-To: leland@cs ()
Organization: Columbia University, Dept. of Computer Science, NYC
Lines: 41

I have an application that requires two discrete uses of both lex and
yacc.  Since both lex and yacc have hardcoded names (all with the 'yy'
prefix) for a whole bunch of global symbols, there is an immediate
problem:  somehow the two sets must be hidden from each other and
distinguished for any other code that accesses them.

I've tried this kludge:  create a header file that re-#define's all the
names 'yyfoo' in lex/yacc set #1 to be named, say, set1yyfoo, and all
those in set #2 to be named set2yyfoo.  This has worked for me in the
past, but won't in this particular instance because the generated
code includes calls to yyless() and yywrap(), which are in the LEX
library (-ll), the contents of which I cannot rename.  So that doesn't
work.

I've also investigated GNU's replacements for these programs, flex and
bison.  I haven't gotten to the bison documentation yet, but a
quick look at the flex man page implies that these programs still
have the hardcoded global symbol names.  Flex eliminates the need
for the external library, however, so this may solve my problem.  But
it's still a horrible kludge, and it would require that others to whom
I distribute the software maintain flex and/or bison.  I'm looking
for something better.

I may be able to use some special loader options to 'hide' the yy*
symbols when compiling the object modules that contain them, but
the procedure for doing is not obvious nor it is standardized across
loader versions.

Has anybody listening gotten into this before?  Can you offer any
suggestions?  Thanks for whatever you may know.

It is difficult to accept that, considering how long these programs have
been around, none of the implementers ever thought to make these globals
static or to add a command-line option to rename them.

Leland Woodbury
-- 
ARPANET/INTERNET: leland@cs.columbia.edu
	  USENET: ...!columbia!cs.columbia.edu!leland
	  BITNET: leland%cs.columbia.edu@cuvmb
	  USMAIL: Columbia Univ., 457 CS, 500 W. 120 St., NYC 10027-6699


Brought to you by Super Global Mega Corp .com