[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: $<out of range>

From: Akim Demaille
Subject: Re: $<out of range>
Date: 25 Apr 2002 21:59:30 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)

>>>>> "Paul" == Paul Eggert <address@hidden> writes:

>> From: Akim Demaille <address@hidden> Date: 25 Apr 2002 17:22:32
>> +0200
>> I suppose the intent is to assign a value to the third symbol,
>> which is the mid-rule action, i.e., it is actually $$ which should
>> be used.

Paul> Yes, $3 is equivalent to $$ here, since it appears in a semantic
Paul> action that is the 3rd component in the rule.

How can it be?  I mean, there is a reduction here, so by definition,
$$ will overwrite $3.  Actually, I was so disturbed that this could
work, that I wrote a test case, and, unless I'm missing something,
even if POSIX says so, Bison doesn't, and G++ is broken somewhere.

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>

#define YYDEBUG 1

static int yylex (void);
static void yyerror (const char *msg);

  int ival;
some: one one;

one: 'a' { $<ival>2 = 42;} 'c' { fprintf (stderr, "%d\n", $<ival>2); }
   | 'b' { $<ival>$ = 53;} 'c' { fprintf (stderr, "%d\n", $<ival>2); }
static int
yylex (void)
  static const int vals[] =
      'a', 'c', 'b', 'c', 0
  static int counter = 0;
  return vals[counter++];

static void
yyerror (const char *msg)
  fprintf (stderr, "%s\n", msg);

main (void)
  yydebug = !!getenv ("YYDEBUG");
  return yyparse ();

Here is bison 1.49:

/tmp % bison out-of-bound.y
out-of-bound.y:20: invalid value: $2

This is 1.28:

/tmp % /usr/bin/bison out-of-bound.y
/tmp % gcc -Wall out-of-bound.tab.c -o out-of-bound
/usr/share/bison/bison.simple: In function `yyparse':
/usr/share/bison/bison.simple:629: warning: implicit declaration of function 
/tmp % ./out-of-bound

>> So, I hope POSIX declares this is an heresy

Paul> No, it's allowed.  POSIX says of `$number':

Paul>   If number refers to an element past the current point in the
Paul> rule, or beyond the bottom of the stack, the result is
Paul> undefined.

Paul> Here the "current point in the rule" is 3, so $3 is allowed.
Paul> Since type checking is enabled, a type is required here, but the
Paul> grammar actually says `$<ttype>3' so it satisfies the
Paul> type-checking requirement too.

POSIX lost its mind.  There is a rule reduction here, so Bison pops
the stack and pushes $$.  What was written in $3 is popped even more.
Either I'm missing something obvious, or really, POSIX asks us to
rewrite the mid-rule actions to use $$.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]