Path: utzoo!attcan!uunet!samsung!olivea!orc!inews!iwarp.intel.com!gargoyle!chinet!bryang From: bryang@chinet.chi.il.us (Bryan Glennon) Newsgroups: comp.lang.c Subject: Re: yacc-a-dy YACC yacc, Help me HACK! Message-ID: <1990Oct11.021808.3114@chinet.chi.il.us> Date: 11 Oct 90 02:18:08 GMT References: <289@cti1.UUCP> Distribution: comp Organization: BPG Consulting, POB 841, Bensenville, Il. 60106 (708) 595-6059 Lines: 53 >From article <289@cti1.UUCP>, by mpledger@cti1.UUCP (Mark Pledger): > > Could somebody please give me a hand with a lex & yacc problem. I am > trying to build a small subset of the SQL language. For purposes of this > question my yacc grammer is defined below. > There are (I think) two problems here. The first is in the lexical analyzer, which returns the token EOC when it sees a semicolon. Unless EOC is defined as ';', this will be a problem, since the cmds rule expects to see select ';': >";" { > yylval.string = yytext; > return(EOC); > } >cmds : select ';' I changed the analyzer to return ';' when it sees a semicolon. The second problem lies in the definition of cmds. It does not recurse, so it will not know what to do with statements other than the first. Anyway, here is the original rule, and the changes I made: >cmds : select ';' > { > fprintf(stdout,"SQL syntax correct.\n"); > } > ; cmds : | cmds select ';' { fprintf(stdout,"SQL syntax correct.\n"); } ; My version seems to work, although I had to guess as to what the symbol lookup routine does. If you want to see my complete test source, drop me a line and I will e-mail it to you. BTW, you don't have to allocate dynamic memory to hold the matched patterns, since yytext is a global. What you do have to be careful of (and I think this is what the response was referring to) is that you don't return the address of local strorage that is created within the analyzer. Hopes this helps... Bryan ...chinet!bryang "Hey, Rock! Watch me pull a ...chinet!bpgc!bryan rabbit outta my hat!" -Bullwinkle