From:	"Campbell, Rolf [SKY:1U32:EXCH]" <cp1v45 AT americasm01 DOT nt DOT com>
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
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

- Raw text -