Errata

For the chapter 3 programs(source code) there is need to add the yyerror function for the compilation to be successful.
Also as pointed in the previous errata we need to add the main function with yyparse().
Here is the complete code that leads to a successful compilation

%{
#include<stdio.h>
%}

%token NAME NUMBER
%%
statement: NAME '=' expression
| expression { printf("= %d\n", $1); }
;

expression: expression '+' NUMBER { $$ = $1 + $3; }
| expression '-' NUMBER { $$ = $1 - $3; }
| NUMBER { $$ = $1; }
;

%%
//extern FILE *yyin;
main()
{

yyparse();

}
int yyerror()
{
printf("Invalid expression");
return 1;
}

int yywrap()
{
return 1;
}

---statements issued for compilation
yacc -d ch3-01.y
lex ch3-01.l
cc lex.yy.c y.tab.c -o ch3-01

Example ch3-01.y should be:

%{
#include<stdio.h>
%}
%token NAME NUMBER
%%
statement: NAME '=' expression
| expression { printf("= %d\n", $1); }
;

expression: expression '+' NUMBER { $$ = $1 + $3; }
| expression '-' NUMBER { $$ = $1 - $3; }
| NUMBER { $$ = $1; }
;
%%

extern FILE *yyin;

main()
{
yyparse();
}

To build it:

yacc -d ch3-01.y
lex ch3-01.l
gcc -o ch3-01 lex.yy.c y.tab.c -ll -ly -lfl

I'm using AIX 4.3 version of 9781565920002 and yacc.
The example doesn't work properly if I don't put return statement
in sentence rule.
sentence: subject VERB object { printf("Sentence is valid.
"); return 0; }
(occurs under FreeBSD, too)

The C code does not have the same behavior as the 9781565920002 code in Example 1-10,
as claimed. In particular, try the following two test cases as input:

.123.456
"Here is an unclosed literal text string

The 9781565920002 code treats the first example as two NUMBERs: .123 and .456, while
the C code has improper control flow and treats it as a single number. By
the time the C code gets to the second decimal point, it has no memory of
whether it started with .123 or just 123 without a leading decimal point.

The 9781565920002 code correctly detects that the second example does not fit any of
its patterns except the default, so it outputs the double quote and then
continues. The remaining words are then categorized as COMMANDs. The C code
makes the erroneous decision that this must be TEXT on the basis of the
double-quote character, even though the quote might never be closed later.

The C code could really stand to be cleaned up quite a bit. The indentation
in the NUMBER case does not match the nesting level, making it quite hard
to read, and the "early K&R hacker" style of the beginning of the code is
obsolete (e.g. use "int main(int argc, ..)"
instead of the "void main(argc, argv)" K&R style shown.)

The following line:

.+ ECHO;

has been left out. This will prevent matching of other strings when not in the
MAGIC start state.

Example ch3-01 does NOT work. I have tried this on a Win PC, SCO Unix, Redhat 7.2
Linux and Suse7.3 Linux. Using both hand-typed code, as well as using the examples
from the ftp site, at NO time does the { printf("= %d
",%1);} ever display on the
screen as it is supposed to.

<safari section 5.3.1> Print page 117, Example 5-3. The first SQL lexer;
void
yyerror(char *s)
{
printf("%d: %s at %s
", lineno, s, yytext);
{

should be

void
yyerror(char *s)
{
printf("%d: %s at %s
", lineno, s, yytext);
}

the final brace is wrong.

In the example "E-1: F9781565920002 specification to parse a command line ape-05.l" in
page 285, at the end of the example we can see the following part of code:

if (targv[0][offset+copylen] == '') { /* end of arg */
buf[copylen] = ' ';
copylen++;
offset = 0;
targv++;
}

The mistake is that here the case in which the length of an argument is longer
than max (that is, the maximum number of characters that can be copied into the
buffer at one time) is not supported. In this case, we can't copy the full
argument into the buffer, but we can only copy a part of the argument. Then,
offset should be updated so as to store the point where we left copying the argument
into the buffer. This is possible by adding to the if-sentence:

else
offset += copylen;