Bison规则中的printf出现问题 [英] Trouble with printf in Bison Rule

查看:177
本文介绍了Bison规则中的printf出现问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经在Bison文件中尝试过类似的操作...

I have tried something like this in my Bison file...

ReturnS: RETURN expression {printf(";")}

...但是分号是在下一个标记之后(超过此规则)而不是在表达式之后立即显示的.制定此规则是因为我们需要将输入文件转换为类似C的格式,并且原始语言在return语句中的表达式后不需要分号,但是C不需要,所以我想我将其添加使用printf手动输出到输出.这似乎不起作用,因为添加了分号,但是由于某种原因,它是在解析下一个标记(在ReturnS规则之外)之后添加的,而不是在表达式规则返回ReturnS时添加的.

...but the semicolon gets printed AFTER the next token, past this rule, instead of right after the expression. This rule was made as we're required to convert the input file to a c-like form and the original language doesn't require a semicolon after the expression in the return statement, but C does, so I thought I'd add it manually to the output with printf. That doesn't seem to work, as the semicolon gets added but for some reason, it gets added after the next token is parsed (outside the ReturnS rule) instead of right when the expression rule returns to ReturnS.

此规则也将导致相同的结果:

This rule also causes the same result:

loop_for: FOR var_name COLONEQUALS expression TO {printf("%s<=", $<chartype>2);} expression STEP {printf("%s+=", $<chartype>2);} expression {printf(")\n");} Code ENDFOR

除了前两个printf不能正常工作(我将发布有关此问题的另一个问题)外,最后一个printf实际上在解析了代码"规则的第一个标记/文字之后实际上被称为,如下所示:

Besides the first two printf's not working right (I'll post another question regarding that), the last printf is actually called AFTER the first token/literal of the "Code" rule has been parsed, resulting in something like this:

for (i=0; i<=5; i+=1
a)
=a+1;

代替

for (i=0; i<=5; i+=1)
a=a+1;

有什么想法我在做什么错吗?

Any ideas what I'm doing wrong?

推荐答案

可能是因为语法必须先预读一个标记,然后才能按照显示的规则进行归约.

Probably because the grammar has to look-ahead one token to decide to reduce by the rule you show.

当规则被简化时执行该动作,这是非常典型的,语法必须在知道可以/应该简化前一条规则之前再读取一个标记.

The action is executed when the rule is reduced, and it is very typical that the grammar has to read one more token before it knows that it can/should reduce the previous rule.

例如,如果一个表达式可以由不确定的附加术语序列组成,则它必须读到最后一个术语之外才能知道没有另一个"+"来继续该表达式.

For example, if an expression can consist of an indefinite sequence of added terms, it has to read beyond the last term to know there isn't another '+' to continue the expression.

在查看了Yacc/Bison语法和Lex/Flex分析器之后,一些问题变得很明显,而其他问题则需要更多解决.

After seeing the Yacc/Bison grammar and Lex/Flex analyzer, some of the problems became obvious, and others took a little more sorting out.

  • 拥有词法分析器进行大量印刷工作意味着语法不能正确控制何时出现.分析仪做得太多.
  • 分析器也没有做足够的工作-可以使语法处理字符串和数字一次只包含一个字符,但是不必要的辛苦工作.
  • 如果需要保留注释,则处理注释非常棘手.在常规的C编译器中,词法分析器将注释丢弃;在这种情况下,必须保留评论.处理该规则的规则已从语法(由于空字符串匹配注释而导致移位/减少和减少/减少冲突)移至词法分析器.这可能并不总是最佳的,但在这种情况下似乎可以正常工作.
  • 词法分析器需要确保在需要值时返回适当的yylval值.
  • 语法需要在$$中传播适当的值,以确保规则具有必要的信息.关键字大部分不需要值.诸如变量名和数字之类的事情.
  • 语法必须在适当的位置进行印刷.
  • Having the lexical analyzer do much of the printing meant that the grammar was not properly in control of what appeared when. The analyzer was doing too much.
  • The analyzer was also not doing enough work - making the grammar process strings and numbers one character at a time is possible, but unnecessarily hard work.
  • Handling comments is tricky if they need to be preserved. In a regular C compiler, the lexical analyzer throws the comments away; in this case, the comments had to be preserved. The rule handling this was moved from the grammar (where it was causing shift/reduce and reduce/reduce conflicts because of empty strings matching comments) to the lexical analyzer. This may not always be optimal, but it seemed to work OK in this context.
  • The lexical analyzer needed to ensure that it returned a suitable value for yylval when a value was needed.
  • The grammar needed to propagate suitable values in $$ to ensure that rules had the necessary information. Keywords for the most part did not need a value; things like variable names and numbers do.
  • The grammar had to do the printing in the appropriate places.

返回的原型解决方案存在严重的内存泄漏,因为它宽松地使用了strdup()并且根本没有使用free().确保泄漏已修复-可能通过使用char数组而不是YYSTYPE的char指针-留给OP.

The prototype solution returned had a major memory leak because it used strdup() liberally and didn't use free() at all. Making sure that the leaks are fixed - possibly by using a char array rather than a char pointer for YYSTYPE - is left to the OP.

这篇关于Bison规则中的printf出现问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆