From: "Campbell, Rolf [SKY:1U32:EXCH]" Newsgroups: comp.os.msdos.djgpp,comp.programming Subject: Bison and [f]lexical tie-ins Date: Fri, 09 Jul 1999 14:08:42 -0400 Organization: Nortel Networks Lines: 30 Message-ID: <37863AAA.BF85DE25@americasm01.nt.com> NNTP-Posting-Host: bmerhc00.ca.nortel.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.6 [en] (X11; I; HP-UX B.10.20 9000/712) X-Accept-Language: en To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com struct a {int a; int b;}; struct b {int a; int b;}; int main() { int a, m(b j), b; b=7; return 0; } This simple little program breaks any attempt I make to parse C code with lexical tie-ins. First of all, if 'a' is a struct, then the tie-in returns it as a type and that breaks the syntax for "int a". I found a way around this by making my flex code a little smarter, and looking for things that look like declarations, but that breaks with the m(b j) delcaration because now it thinks b is a variable name. And, worst of all, even if I could resolve all of these problems, Bison uses a look-ahead token. This means that before 'b' gets identified as a local variable, 'b' get's read in (by flex, from the line after) and called a typename and Bison sees it as 'typename = 7' which, of course, is a syntax error! I could just remove support for delcaring functions in a comma-delimiated list, but that still wouldn't get rid of the last mentioned problem. Any ideas or thoughts on the situation would be appreciated. -- -Rolf Campbell (39)3-6318