![]() |
|
#1
|
|||
|
|||
Flex and bison codingI need help with correcting my errors of this parse program
scan.l CPP / C++ / C Code:
parse.y CPP / C++ / C Code:
Code:
I am unable to correct the errors. Please help me out with this. Last edited by admin : 20-Dec-2007 at 18:35.
Reason: Please insert your example C/C++ codes between [CPP] and [/CPP] tags
|
|||
|
#2
|
|||
|
|||
Re: Flex and bison codingBased on my understanding of the parsers
I had comment on this as of now. CPP / C++ / C Code:
It should be CPP / C++ / C Code:
|
|
#3
|
|||
|
|||
Flex and bison codingI am new to the parser coding. I have written a code but am unable to understand the errors. Can someone please help me out with it.
My code: scan.l CPP / C++ / C Code:
parse.y CPP / C++ / C Code:
Although I declared PLUS, MINUS, ... I still get these errors: Code:
Last edited by admin : 21-Dec-2007 at 18:19.
Reason: Please insert your example C/C++ codes between [CPP] and [/CPP] tags
|
|
#4
|
|||
|
|||
Re: Flex and bison codingQuote:
I have been waiting to see whether any bison/yacc experts or lex/flex experts (lexperts? flexperts?) would respond, since I haven't played with these for years. Seeing no other volunteers, I will have a shot at it, and hope that it isn't too late to offer help. First of all, I will say that i find lex/flex a lot of fun, and people writing compilers or parts of compilers have used it over the years along with yacc to resolve and implement various types of grammars. See Footnote. I will walk through a few steps with flex and bison as I use them on my Linux system. Since you posted something.l and something.y and you showed error messages for something.c, I will try to fill in a few blanks for people playing at home: The file scan.l has a statement #include parse.h. That statement is not processed by flex, but will be processed by gcc. Since gcc didn't complain, I will assume that you, indeed, have a file named parse.h Where does parse.h come from? Well we run bison on parse.y with a "-d" command line switch to get bison to create a header file and a C source file: bison -d parse.y Bison creates two files: parse.tab.h parse.tab.c Here is one difference between bison and yacc: yacc would create the following two files: y.tab.h y.tab.c If we run bison with "-y" it creates the same file names as yacc---that's handy for users with old scripts or makefiles that use the yacc names. (Note that versions of yacc ported to DOS systems might actually create file with the old 8.3 names, so you might actually get parse.h and parse.c) However, I will just run bison -d and rename the files. bison -d parse.h mv parse.tab.c parse.c mv parse.tab.h parse.h (For people on Windows, use "ren" to rename the files, instead of "mv", unless they are using a bash-like shell.) Now, when you run flex on a file, it creates a file named lex.yy.c. I will rename that file, as follows: flex scan.l mv lex.yy.c scan.c At this point there are three new files: parse.c parse.h scan.c When I run gcc on scan.c, I get all of your errors and one more Code:
So, either your makefile (or other script) did something about yy_flex_debug that I don't know about, or your version of bison or flex does something that I don't know about. For now, I will simply put the following line in the scan.l, just before your "int my_yy_flex_debug;" statement. (We might have to do something more useful later.) Code:
OK, now we are ready to look at the errors. First of all, the following three messages come from flex: Code:
This is a significant indicator that your scan.l file has some functional shortcomings. It will (probably) not work as you intended. They do not, however interfere with gcc, and do not cause anything that we worry about just yet. They may very well play a big part in debugging the bloomin' thing after we get it to compile. Now, the "good stuff". This is the "C" stuff (although this is the C++ forum). First of all note that although we are compiling scan.c, the messages refer back to scan.l. What a great thing they they have done for us!!! The hundred or so lines of scan.l have given us over 1500 lines of C code, most of which came from flex, not from scan.l. Just showing us what line of the C file it was having a problem with wouldn't be nearly as useful as showing us what line of scan.l created the problem Look (yes, look) at the first message, and the line in scan.l that it refers to: Here's my message (my line number is one greater than yours, since I had to add a line): Code:
CPP / C++ / C Code:
Question: What is argument 2 of number? Answer: It is yylval Question: What is the variable type of argument 2 ofg number(), as defined in scan.l? Answer: it is a pointer to some data type YYSTYPE Now, without even knowing what the heck YYSTYPE is, a good guess might be that the problem may be that we should supply a pointer as argument 2 to number(), and we have supplied a variable that is not a pointer. Looking a little closer, I find the following in parse.h CPP / C++ / C Code:
So, indeed, the data type of yylval is YYSTYPE, and argument 2 of number requires a pointer to YYSTYPE. Bottom line: As much fun as flex and bison are, you still have to use your finely-honed debugging skills (that you learned when studying C) to get to the bottom of things. After all, people writing compilers (or parts of compilers, like parsers) should know something about the language they are dealing with. I can't imagine someone with no C programming knowledge or experience trying to make some sense out of a flex-based scanner and a bison-based parser. (But that's just me: I have a somewhat limited imagination.) It's a detective story. Look at the clues. Follow the clues. You might even look for complete examples on the web or in books (or class notes or whatever) that actually do useful (or at least functional) things with lex-based scanners and bison-based parsers. If you have further questions, then post your progress and ask specific questions. Examine the messages and examine the code. Ask about anything that you don't understand, but be specific Regards, Dave Footnote: The original Lexical expression scanner, named lex, has been implemented on many systems. The GNU version, called flex, is available on Linux systems and also cygwin/Window systems. On my systems, "lex" is just a symbolic link to "flex." The "yacc" program (yet another compiler-compiler) has also been implemented on many systems. My Linux system has Bison, the GNU spinoff of yacc. It differs in some details, but the funcitonality is more-or-less upward compatible. There is also a separt "yacc", not just a symbolic link to Bison. I don't know its pedigree. Anyhow, these programs and their spinoffs have undergone lots of changes over the years in varyingly-successful attempts to keep compatible with later revisions of currently-available C compilers. Bottom line: unless you are using the exact same versions of lex/flex and yacc/bison as the original authors, some of the examples that you find on the web or in books may not work. (Some of them might not have been very good to start with. Don't get me started...) They may require minor fixups or they may require major surgery, or they may be best handled by throwing them away and starting with documentation for your version of the tools. A final note: My compiler-writing friends (from back in the 70's) tell me that as much as they enjoyed playing with lex. serious efforts would have most of the functionality (the state machines associated with the grammar productions) would be handled by (the much more powerful) yacc. Debugging was easier when the scanner was very simple. Or that's how I remember it from so long ago. Last edited by davekw7x : 24-Dec-2007 at 10:55.
|
|
#5
|
|||
|
|||
Re: Flex and bison codingQuote:
Where did you declare those things? In parse.y? How the heck would you think gcc could find them when you compile scan.c? What operating system are you using? Where did your version of flex (or is it lex?) come from. What about bison? How are you compiling? What the heck is bison.simple? Look at my previous post to see how to get bison to create a header file. If you put an #include statement in scan.l as was shown in the other scan.l post in this thread, it will make the definitions from parse.y available to gcc when it compiles scan.c. Then you will, maybe, see the errors of the original post in this thread. Go from there. Regards, Dave Footnote: I hope you two guys give credit for the scan.l and parse.y files that you posted. Saying "i have written..." and "My code..." implies some originality. P.S. Note to moderator: If there are any additional posts in this thread, I respectfully suggest that the thread be moved to the "Miscellaneous Program Forum," since I think further issues may be more related to flex and bison rather than C. (And definitely not C++, since there is no C++ involved.) If you do move the thread, then this P.S. can be deleted.) |
|
#6
|
|||
|
|||
Re: Flex and bison codingQuote:
Note that I did not claim to be a flexpert. If I were, I would have immediately recognized that to use yy_flex_debug, you invoke flex with a "-d" command-line option (lex didn't have this option or variable in the olden days, as I recall---but I could be wrong). So, you don't have to add the extra line that I showed if you do the following: flex -d scan.l This will be very useful to find the numerous bugs in the lexer, if we ever get that far. You really don't want to debug a lexer that was compiled without the "-d" (at least I don't). Regards, Dave |
Recent GIDBlog
Install Adobe Flash - Without Administrator Rights by LocalTech
| Thread Tools | Search this Thread |
| Rate This Thread | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Flex, bison multifunction calculator | annatsos | C Programming Language | 6 | 03-May-2007 10:50 |
Network Sites: GIDNetwork · GIDWebHosts · GIDSearch · Learning Journal by J de Silva, The