Path: utzoo!attcan!uunet!mstan!amull
From: amull@Morgan.COM (Andrew P. Mullhaupt)
Newsgroups: comp.lang.c
Subject: Re: yacc sorrows
Summary: Lex vs. Flex
Message-ID: <733@s5.Morgan.COM>
Date: 15 Feb 90 21:10:27 GMT
References: <7179@arcturus> <1990Feb9.171557.18465@tcsc3b2.tcsc.com> <22529@mimsy.umd.edu>
Organization: Morgan Stanley & Co. NY, NY
Lines: 29

In article <22529@mimsy.umd.edu>, chris@mimsy.umd.edu (Chris Torek) writes:
> In article <1990Feb9.171557.18465@tcsc3b2.tcsc.com> prs@tcsc3b2.tcsc.com
> (Paul Stath) writes:
> >The string that gets matched in LEX is stored in a character pointer called
> >`yytext'.
> 
> Actually, this is an array (of size YYLMAX, typically 200) of characters,
> not a pointer.

Yes, if you're referring to real live 'lex'. If you have 'flex' instead,
it gets declared as a pointer to character. 

This discrepancy, typical of those between yacc and bison, is small
but annoying. Does anyone know what the reason is for this one?

Discrepancies aside, the documentation for bison is a pretty good
surrogate for yacc. Two books _The UNIX Programming Environment_
by Kernighan and Pike, and _UNIX Utilities_ by R.S. Tare provide
tutorials on yacc. 

Although you should be able to get yacc to generate the parser you
want independent of what OS you're running, there are some differences
of note. System V UNIX has text messages for debugging a yacc parser
based on the production in the grammar specification, and BSD UNIX
(and Bison) provide references to the production by number, but also
give the stack state. 

Later,
Andrew Mullhaupt