Re: ver 1.50 crashes

[rosing]

The patch worked. Thanks.

You're welcome to have the test case.  Therre's no copyright. I was
just playing. 

Could you explain to me how the tables are compressed?  For each state
there's a table that decides whether to shift or reduce for each
potential token but only a few tokens are of interest.  This results
in a sparse table.  Somehow these tables are compressed to remove a
lot of zeros.

Matt


Akim Demaille writes:
 > 
 > | | Hi,
 > | | I was messing around with bison-1.50 and the following program causes
 > | | it to crash.  I tried reducing this program and I can't without
 > | | removing whatever causes it to crash.  Example: removing the BINOP
 > | | token, which isn't used or simplifying most other rules. If there's a
 > | | better place to send this please let me know.
 > | 
 > | How bizarre... I don't observe this myself.  What is your
 > | architecture?  By any chance, is it a 64 bit platform?  Bison is known
 > | to have problems there, and it was fixed since then: that will be
 > | 1.51.
 > | 
 > | Are there any special options you passed?
 > | 
 > | /tmp % bison gram.y --report=all                                  nostromo 
 > 9:39
 > | gram.y: AVERTISSEMENT: 21 conflits par décalage/réduction et 16 conflits 
 > par réduction/réduction
 > | 
 > | 
 > | If ever your architecture is not 64 bits, I'm interested in the traces
 > | of `bison --trace=all gram.y'.  Thanks!
 > | 
 > | PS/  Please, report bugs to bug-bison, not help.
 > 
 > Please, keep the CC onto the list!
 > 
 > Well, I have it, and I must say the bug is amazing...  I think that if
 > you apply the following patch, everything will be OK.
 > 
 > ~/src/bison % diff -u src/tables.c.orig src/tables.c -u10         nostromo 
 > Err 1
 > --- src/tables.c.orig   2002-10-14 12:08:34.000000000 +0200
 > +++ src/tables.c        2002-10-14 12:05:21.000000000 +0200
 > @@ -773,21 +773,21 @@
 >  `-------------------------------------------------------------*/
 >  
 >  static base_t
 >  table_ninf_remap (base_t tab[], size_t size, base_t ninf)
 >  {
 >    base_t res = 0;
 >    size_t i;
 >  
 >    for (i = 0; i < size; i++)
 >      if (tab[i] < res && tab[i] != ninf)
 > -      res = base[i];
 > +      res = tab[i];
 >  
 >    --res;
 >  
 >    for (i = 0; i < size; i++)
 >      if (tab[i] == ninf)
 >        tab[i] = res;
 >  
 >    return res;
 >  }
 >  
 > 
 > I'm astonished that no other grammar fell onto that problem.  I'm also
 > surprised I never noticed: it means some of the YY*_NINF guys don't
 > fall into the proper range.
 > 
 > Can I use your grammar as test case please?  What is its license?