Bison infix calculator always evaluates as 0 - c

Question

I'm reading a book I found on the Internet about GNU Flex/Bison. And it's pretty cool. One of the examples involves writing an infix calculator. And that goes fine.
The problem is, the book uses int as YYSTYPE, which creates obvious issues when, say, dividing 1 by 2. So I decided I'd modify the program to use float instead. So far, so good. The program (source is given below) compiles fine, but always gives an answer of 0, no matter what the calculation is. I've no idea how to debug it either, as it's obviously generated code.
calc.l
%{
#include "parser.h"
%}
%%
"+" { return ADD; }
"-" { return SUB; }
"*" { return MUL; }
"/" { return DIV; }
[0-9]+ {
yylval = atof(yytext);
return NUMBER;
}
\n { return EOL; }
[ \t] { ; }
. { yyerror("Unknown symbol"); }
%%
calc.y
%{
#include <stdio.h>
#define YYSTYPE float
%}
%token NUMBER
%token ADD SUB MUL DIV
%token EOL
%%
/* List of expressions */
calclist:
| calclist AS_result EOL { printf("%f\n-> ", $2); }
;
/* Add/subtract result. Evaluated after multiply/divide result */
AS_result: MD_result
| AS_result ADD MD_result { $$ = $1 + $3; }
| AS_result SUB MD_result { $$ = $1 - $3; }
;
/* Multiply/divide result. Evaluated first. */
MD_result: NUMBER
| MD_result MUL NUMBER { $$ = $1 * $3; }
| MD_result DIV NUMBER { $$ = $1 / $3; }
;
%%
int yyerror(char *msg)
{
printf("Error: '%s'\n", msg);
return 0;
}
int main(int argc, char **argv)
{
printf("-> ");
yyparse();
return 0;
}
Makefile
make: calc.l calc.y
bison -Wall -o parser.c --defines=parser.h calc.y
flex -o scanner.c calc.l
cc -ggdb -o calc scanner.c parser.c -lfl
clean:
rm -f parser.c parser.h scanner.c calc.c calc
Example run
michael#michael-desktop:~/code/calculator$ ./calc
-> 1 + 2
0.000000
-> ^C
michael#michael-desktop:~/code/calculator$
Feedback on any part of the code is appreciated as well as the actual problem. Cheers!

Answer 1

You're right, it works only for division -- strange.. I haven't noticed, shame on me.
Here is another thing to try:
calc.y:
%{
#include <stdio.h>
%}
%union { double d; }
%token <d> NUMBER
%token ADD SUB MUL DIV
%token EOL
%type <d> MD_result AS_result
%%
calc.l: change the line "yylval = atof(yytext);" with:
yylval.d = atof(yytext);
Now it says:
-> 1+2
3.000000
-> 2*3
6.000000
-> 4-5
-1.000000
-> 6/4
1.500000
as expected.

Answer 2

in calc.y: add a second define:
%{
#include <stdio.h>
#define YYSTYPE float
#define YYSTYPE_IS_DECLARED
%}
And then..
./calc
-> 1/3
0.333333

Answer 3

Your proposal, and its correction by #Michael, does not work because the #define YYSTYPE is not propagated to the scanner. The %{ %} block is solely for bison (well, for the generated parser), it is not exported in the generated header. Read the documentation about %code to see what needs to be done: http://www.gnu.org/software/bison/manual/bison.html#g_t_0025code-Summary. In your case, %code requires is appropriate:
%code requires
{
# include <stdio.h>
# define YYSTYPE float
# define YYSTYPE_IS_DECLARED
}
It is easy to see what is going wrong once you equipped your parser with debug actions:
%debug
%printer { fprintf(yyoutput, "%f", $$); } <>
and
int main(int argc, char **argv)
{
printf("-> ");
yydebug = !!getenv("YYDEBUG");
yyparse();
return 0;
}
You'll see:
Reading a token: -> 1+2
Next token is token NUMBER (0.000000)
Shifting token NUMBER (0.000000)
Entering state 3
Reducing stack by rule 6 (line 28):
$1 = token NUMBER (0.000000)
-> $$ = nterm MD_result (0.000000)
Stack now 0 1
Entering state 5
Reading a token: Next token is token ADD (0.000000)
Reducing stack by rule 3 (line 22):
$1 = nterm MD_result (0.000000)
-> $$ = nterm AS_result (0.000000)
Stack now 0 1
Entering state 4
Next token is token ADD (0.000000)
Shifting token ADD (0.000000)
Entering state 6
Reading a token: Next token is token NUMBER (0.000000)
Shifting token NUMBER (0.000000)
Entering state 3
Reducing stack by rule 6 (line 28):
$1 = token NUMBER (0.000000)
-> $$ = nterm MD_result (0.000000)
Stack now 0 1 4 6
Entering state 11
Reading a token: Next token is token EOL (0.000000)
Reducing stack by rule 4 (line 23):
$1 = nterm AS_result (0.000000)
$2 = token ADD (0.000000)
$3 = nterm MD_result (0.000000)
-> $$ = nterm AS_result (0.000000)
which shows that when I type in "1+2", it actually sees 0.00000 about everywhere.
Now, how come it "works" for division? By accident, because float division and int division are very alike at the bit level. Toy with the following program which repeats the mistake: fill variables as integers, but use them as floats.
#include <stdio.h>
union YYSTYPE
{
int ival;
float fval;
};
#define TRY(L, O, R) \
do { \
union YYSTYPE lhs, rhs, res; \
lhs.ival = L; \
rhs.ival = R; \
res.fval = lhs.fval O rhs.fval; \
fprintf (stdout, "d. %d %s %d => %f\n", \
lhs.ival, #O, rhs.ival, res.fval); \
fprintf (stdout, "x. %x %s %x => %x\n", \
lhs.ival, #O, rhs.ival, res.ival); \
} while (0)
int main()
{
TRY(1, /, 2);
TRY(1, *, 2);
TRY(1, -, 2);
TRY(1, +, 2);
return 0;
}
But then, of course, the right answer is not to use #define YYSTYPE, which is way too coarse grained, but to use %union, as #Michael suggested.