Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #2143 > unrolled thread

Why do some versions of bison require {} here?

Back to article view | Back to comp.compilers

Contents

  Why do some versions of bison require {} here? Philipp Klaus Krause <pkk@spth.de> - 2019-01-01 10:55 +0100
    Re: Why do some versions of bison require {} here? Kaz Kylheku <157-073-9834@kylheku.com> - 2019-01-02 19:29 +0000
    Re: Why do some versions of bison require {} here? Philipp Klaus Krause <pkk@spth.de> - 2019-01-03 09:15 +0100
      Re: Why do some versions of bison require {} here? Kaz Kylheku <157-073-9834@kylheku.com> - 2019-01-04 03:02 +0000

#2143 — Why do some versions of bison require {} here?

In SDCC.y, there are rules:

program
   : external_definition
   | program external_definition
   ;

external_definition
   : function_definition
        {
          // blockNo = 0;
        }
   | declaration
        {
          ignoreTypedefType = 0;
          if ($1 && $1->type && IS_FUNC($1->type))
            {
              /* The only legal storage classes for
               * a function prototype (declaration)
               * are extern and static. extern is the
               * default. Thus, if this function isn't
               * explicitly marked static, mark it
               * extern.
               */
              if ($1->etype && IS_SPEC($1->etype) && !SPEC_STAT($1->etype))
                {
                  SPEC_EXTR($1->etype) = 1;
                }
            }
          addSymChain (&$1);
          allocVariables ($1);
          cleanUpLevel (SymbolTab, 1);
        }
   | addressmod
   ;

which has always worked for me without problems on all yacc / bison I
tried. But sporadically, users reported that this failed for them, and
they had to change the last two lines to:

   | addressmod
        {
        }
   ;

for their yacc / bison to accept the rule.
What is happening here? Why is the {} required? Why only on the last
rule, while the first one is okay?

Philipp
[Adding the empty action forces bison to reduce the rule rather than just
shifting and saving state for later.  I couldn't guess why that would matter
in this case.  Are there precedence rules?  With your change does the grammar compile
cleanly or does it have conflicts? -John]

[toc] | [next] | [standalone]

#2144

On 2019-01-01, Philipp Klaus Krause <pkk@spth.de> wrote:
>    | addressmod
>         {
>         }
>    ;
>
> for their yacc / bison to accept the rule.
> What is happening here? Why is the {} required? Why only on the last
> rule, while the first one is okay?
>
> Philipp
> [Adding the empty action forces bison to reduce the rule rather than just
> shifting and saving state for later.  I couldn't guess why that would matter
> in this case.  Are there precedence rules?  With your change does the grammar compile
> cleanly or does it have conflicts? -John]

What, John? Shouldn't a missing action be equivalent to { $$ = $1 }?

Here, found it in Bison's manual, "3.4.6 Actions":

  If you don’t specify an action for a rule, Bison supplies
  a default: $$ = $1.

That should imply that there in fact is an action that requires a
reduction. Unless Bison handles this case specially without a reduce
somehow?

--
TXR Programming Lanuage: http://nongnu.org/txr
Music DIY Mailing List:  http://www.kylheku.com/diy
ADA MP-1 Mailing List:   http://www.kylheku.com/mp1
[Oops, you're quite right.  It's been a decade since I revised
flex+bison and the brain cells are tired.  Now I'm just baffled
unless there is some syntax error that the extra rule is somehow
fixing. -John]

[toc] | [prev] | [next] | [standalone]

#2145

Am 01.01.19 um 10:55 schrieb Philipp Klaus Krause:
> [Adding the empty action forces bison to reduce the rule rather than just
> shifting and saving state for later.  I couldn't guess why that would matter
> in this case.  Are there precedence rules?  With your change does the grammar compile
> cleanly or does it have conflicts? -John]
>

Well, for me (but I don't see the problem without the {} on my system -
GNU bison 3.2.2 on Debian GNU/Linux), both with and without {}, when using
LANG=C bison -W -y -d SDCC.y
I get 7 warning about "empty rule without %empty", but no other
warnings. The people reporting issues seem to be using GNU bison on
Microsoft Windows.

Philipp

[toc] | [prev] | [next] | [standalone]

#2146

On 2019-01-03, Philipp Klaus Krause <pkk@spth.de> wrote:
> Am 01.01.19 um 10:55 schrieb Philipp Klaus Krause:
>> [Adding the empty action forces bison to reduce the rule rather than just
>> shifting and saving state for later.  I couldn't guess why that would matter
>> in this case.  Are there precedence rules?  With your change does the grammar compile
>> cleanly or does it have conflicts? -John]
>>
>
> Well, for me (but I don't see the problem without the {} on my system -
> GNU bison 3.2.2 on Debian GNU/Linux), both with and without {}, when using
> LANG=C bison -W -y -d SDCC.y
> I get 7 warning about "empty rule without %empty", but no other
> warnings. The people reporting issues seem to be using GNU bison on
> Microsoft Windows.

Another thing to look at: does it make any difference the generated .c and .h
files. (And if so, what is the difference in the y.output produced by
the -v option).

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compilers

csiph-web