Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.unix.wizards
Subject: Re: A complete example (long) (was Re: yacc & lex - cupla questions)
Keywords: yacc, lex, i/o redirection, value of tokens
Message-ID: <867@mwtech.UUCP>
Date: 29 Jul 90 14:45:10 GMT
References: <1990Jul26.175831.1216@uicbert.eecs.uic.edu> <640@atcmpe.atcmp.nl> <242@risky.Convergent.COM>
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Distribution: comp
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 58

In article <242@risky.Convergent.COM> sun!pyramid!ctnews!pase60!gilles (Gilles Courcoux) writes:
[some lines deleted]

>A2)
>It is a make(1) problem. Look at the doc's.
>Remember the YFLAGS you see when you type:
>	$ make -pn	# 'list macros' flag and 'do nothing' flag
>
>it contains the flags the implicite rule .y.o: will use when
>updating your yacc.o file from the yacc.y file. So just enter the
>following line in your makefile
>YFLAGS = -d

First, this isn't enough, since the suffix rules also may need to
rename y.tab.h. At least, if your makefile can generate different
grammars, you can not leave a file with this name.

Second assume you have garmmar.y, grammar.c and grammar.h. Now if
you build something that depends on grammar.c, yacc will called
with the "-d"-flag. But how shall make know how it can build an
uptodate grammar.h?
>
>More than a lot of words, let me draw the picture of a simple parser
>that split an input file into words blank separated, and that show
>you the redirection features of LEX at work.
>
>The sample input file is tst.input, the obtained output is
>tst.output as shown in the makefile command line corresponding to
>the all: target.
>
>Hope this helps you, and that it is self explanatory.

I don't doubt in the good intentions of the poster and I know the
difference between examples and production code, but IMHO there are
places, where the fact that error checking should at least be *added*
later, are necessary:

>		yyout = fopen(argv[2], "w");
>		if (! yyout)
>			quit("Cannot access output file %s\n", argv[2]);
>		/* fall through !!! */

Fine, the poster seems to take my view.

>		yyin = fopen(argv[1], "r");
>		if (! yyin)
>			quit("Cannot access input file %s\n", argv[1]);

Fine again, ...

>	yylval.string = malloc(strlen(yytext)+1);
>	strcpy(yylval.string, yytext);

OOPS!?!
Seems that malloc never fails?
Or is strcpy responsible for coping with NULL-pointers?
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83