yacc sorrows
Victor Kan
kan at dg-rtp.dg.com
Wed Feb 21 13:12:47 AEST 1990
In article <1044 at targon.UUCP> andre at targon.UUCP (andre) writes:
>In article <7179 at arcturus> evil at arcturus.UUCP (Wade Guthrie) writes:
> >My problem is this: I am trying to get access to the strings that
> >got matched by lex to make the tokens which are passed to yacc.
> >Given this, I can do the job (I think). This is on a sun 3/60 under
Try looking at the yytext array declared in lex.yy.c.
You'll have to extern char *yytext[] it in y.tab.c, unless you
do #3 as suggested below by andre at targon.UUCP. But I've had
nothing but problems with that trick.
>If you declare a union for the yacc stack, you must do two
>things to use the union.
>
>1 tell yacc with (non) terminals have which type
>2 let the lex code fill the members of the
> global union yylval.
>3 (easier) put an include lex.yy.c in the last part
> of the yacc file then you need not fiddle with the include
> file.
You may wish to avoid #3 if you can. It's not a good idea to
#include C files because it can make debugging a living nightmare.
Your compiler will give you bogus line numbers for syntax errors and
warnings. When you're program gets to the debugging stage,
breakpoints in your debugger may be bogus too. GCC 1.35 and GDB 3.2
don't handle the line numbering and symbol table correctly in this
respect. I doubt other compilers/debuggers can do any better.
Besides, it takes very little effort to support a separate y.tab.c
and lex.yy.c with y.tab.h declarations. A little laziness here can
cause you unnecessary Exedrin headaches.
>lex:
>%%
>[a-zA-Z][a-zA-Z0-9_]* { yylval.str = strncpy(malloc(yyleng+1), yytext, yyleng);
yylval.str = strdup (yytext); works fine.
Just remember to free the block when you're done with it in Yacc.
>yacc:
>
>%%
>#include "lex.yy.c"
Avoid this if you can!!!!!
| Victor Kan | I speak only for myself. | ***
| Data General Corporation | Edito cum Emacs, ergo sum. | ****
| 62 T.W. Alexander Drive | Columbia Lions Win, 9 October 1988 for | **** %%%%
| RTP, NC 27709 | a record of 1-44. Way to go, Lions! | *** %%%
More information about the Comp.lang.c
mailing list