Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!infonode!ingr!b11!polfer From: polfer@b11.ingr.com (? Polfer) Newsgroups: comp.lang.c Subject: Re: two (or more) lex's/yacc's in one executable Message-ID: <9603@b11.ingr.com> Date: 10 Dec 90 16:29:43 GMT References: <1990Dec6.200944.13037@cs.columbia.edu> Reply-To: polfer@b11.UUCP (Dan Polfer) Organization: Intergraph Corp. Huntsville, AL Lines: 54 In article <1990Dec6.200944.13037@cs.columbia.edu> leland@cs () writes: >I have an application that requires two discrete uses of both lex and >yacc. [...] >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. Trying to redefine all of the symbols can be a real pain in the neck. Try to use "#define yy set1yy" or "#define yy set2yy" at the top of your different parser files, and then have the parser files include the lex code (catching all of the lex symbols). >[...] 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. The LEX library (libl.a) includes default objects for yyless, yywrap, reject, main, and allprint (a routine used by the builtin debug code). Each of these routines are fairly trivial, and can be replaced by you with little effort. For example, the yywrap code in libl.a is equivalent to the following: int yywrap () { return(1); } yyless is about as tough, you simply use the unput routine to push the last few characters of yytext back onto the input stream. Note that there is a stated limit of 100 characters on unput (although I've observed 200). Also, remember that in your lex/yacc files, you must use yytext (not set1yytext) because the macro definition will take care of the translation. As far as unput, input, and output are concerned, LEX usually defines these as macros so there is no danger unless you have implemented the routines as functions and undefined the macros. Replacing the routines with your own will allow you to kill the link dependancy on libl.a. >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 and Bison can produce code for "isolated" modules (for lack of a better name), but Bison is from the Free Software Foundation so you need to follow their usual conventions (your code becomes free, etc). I'm not sure about Flex, but I didn't think it had the same restrictions (it's from a California University, Berkely maybe?). Anyway, hope the above helps! -- Dan Polfer ...uunet!ingr!b29!dap!dan (UUCP) Intergraph Corporation b29!dap!dan@ingr.com (Internet) Huntsville, Al (205) 730-6154