bc: partially rewrite parser, tests pass, ^C might be broken now
The entire control construct (if/while/for/funcdef) or {} block is
"eaten" by the corresponding parsing function, instead of maintaining
special "block flag stack" with magic bits in it, and returning to main
input loop after every inner statement (every input line, essentially).
This required moving line input deep into lexer - now zbc_lex_next()
triggers more reading when needed.
"block flag stack" is gone.
Correctness of ^C handling wasn't checked, might need fixing now.
if/else syntax is changed to match GNU bc: "else" can not be on
the next line (the rationale is that "if (1) 2" statement in interactive
mode should execute and print 2 instead of waiting for possible
"else ..." line).
This change fixes the following examples:
if (1) if (1) 1 else 2 else 3
if (0) 1 else if (1) 2
define w() { auto z; return 1; }
function old new delta
zbc_parse_stmt_possibly_auto - 2232 +2232
zbc_vm_process 89 561 +472
zbc_lex_next 1982 2296 +314
bc_vm_init 749 757 +8
bc_parse_expr_empty_ok 2016 2021 +5
bc_num_printNewline 54 51 -3
zbc_program_read 289 280 -9
bc_parse_free 47 38 -9
bc_parse_reset 126 113 -13
bc_parse_create 108 92 -16
bc_parse_push_block_flag 47 - -47
bc_parse_noElse 48 - -48
zbc_parse_text_init 113 59 -54
zbc_parse_body 121 - -121
zbc_parse_else 125 - -125
zbc_parse_endBody 254 - -254
bc_vm_run 421 134 -287
zbc_parse_auto 290 - -290
zcommon_parse 476 - -476
zbc_parse_stmt 1682 7 -1675
------------------------------------------------------------------------------
(add/remove: 1/7 grow/shrink: 4/8 up/down: 3031/-3427) Total: -396 bytes
text data bss dec hex filename
982586 485 7296 990367 f1c9f busybox_old
982138 485 7296 989919 f1adf busybox_unstripped
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
3 files changed