Re: Bison 1.30d

[Akim Demaille]

| At 14:24 +0100 2001/11/20, Akim Demaille wrote:
| >A single missing `\n' was responsible of some failures of 1.30c.  This
| >is fixed.  Hopefully, *this* is 1.31.
| ...
| >  ftp://alpha.gnu.org/gnu/bison/bison-1.30d.tar.gz   (660 kB)
| 
| (Looking forward to 1.30d :-).)
| 
| I get the
|   Link Error   : undefined 'trace_flag' (data)
|   Referenced from 'new_itemsets' in LR0.c
|   Referenced from 'set_firsts' in closure.c
|   Referenced from 'set_nullable' in nullable.c
|   Referenced from 'set_derives' in derives.c
|   Referenced from 'reduce_grammar' in reduce.c
|   Referenced from 'longopts' in getargs.c
| You should probably have a line
|   int trace_flag = 0;
| in getargs.c.

???  I don't understand this:

| src/bison-1.29/src % fgrep trace_flag *.c                        nostromo 
12:55
| closure.c:  if (trace_flag)
| closure.c:  if (trace_flag)
| closure.c:  if (trace_flag)
| closure.c:  if (trace_flag)
| derives.c:  if (trace_flag)
| getargs.c:int trace_flag = 0;
| getargs.c:  {"trace",           no_argument,    &trace_flag, 1},
| LR0.c:  if (trace_flag)
| LR0.c:  if (trace_flag)
| LR0.c:  if (trace_flag)
| LR0.c:  if (trace_flag)
| LR0.c:  if (trace_flag)
| nullable.c:  if (trace_flag)
| nullable.c:  if (trace_flag)
| reduce.c:  if (trace_flag)

and the tarball seems right:

| src/bison-1.29/src % /tmp                                        nostromo 
12:55
| /tmp % wget ftp://alpha.gnu.org/gnu/bison/bison-1.30d.tar.gz     nostromo 
12:56
| --12:56:20--  ftp://alpha.gnu.org/gnu/bison/bison-1.30d.tar.gz
|            => `bison-1.30d.tar.gz'
| Connexion vers proxy.epita.fr:3128...Connecté!
| Proxy request sent, awaiting response... 200 OK
| Longueur: 671,568 [application/x-tar]
| 
|     0K .......... .......... .......... .......... ..........  7% @  86,66 
KB/s
|    50K .......... .......... .......... .......... .......... 15% @ 138,50 
KB/s
|   100K .......... .......... .......... .......... .......... 22% @ 138,89 
KB/s
|   150K .......... .......... .......... .......... .......... 30% @ 138,89 
KB/s
|   200K .......... .......... .......... .......... .......... 38% @ 131,23 
KB/s
|   250K .......... .......... .......... .......... .......... 45% @ 134,77 
KB/s
|   300K .......... .......... .......... .......... .......... 53% @ 142,05 
KB/s
|   350K .......... .......... .......... .......... .......... 60% @ 142,05 
KB/s
|   400K .......... .......... .......... .......... .......... 68% @ 136,24 
KB/s
|   450K .......... .......... .......... .......... .......... 76% @ 144,09 
KB/s
|   500K .......... .......... .......... .......... .......... 83% @ 140,06 
KB/s
|   550K .......... .......... .......... .......... .......... 91% @ 130,89 
KB/s
|   600K .......... .......... .......... .......... .......... 99% @ 141,64 
KB/s
|   650K .....                                                 100% @ 142,15 
KB/s
| 
| 12:56:27 (132,17 KB/s) - `bison-1.30d.tar.gz' sauvegardé [671568/671568]
| 
| /tmp % tar zxf bison-1.30d.tar.gz bison-1.30d/src/getargs.c      nostromo 
12:56
| /tmp % fgrep trace_flag bison-1.30d/src/getargs.c                nostromo 
12:56
| int trace_flag = 0;
|   {"trace",             no_argument,    &trace_flag, 1},




| Also, in file output.c, you have forgotten
|    #include <alloca.h>
| as you are calling it in output_stos():
|    short *values = (short *) alloca (sizeof (short) * nstates);

Yep, thanks for spotting it.

| Is it really prudent to call alloca here, in view of that alloca is not in
| the C standard (unless it is in C99) so not all compilers may have it, and
| also, alloca is not called anywhere else in the Bison code?

I wandered too.  As a matter of fact, Bison does have an
AC_FUNC_ALLOCA, so without really looking for other uses, I trusted
the GNU Build System.  In fact, it is only used in lib/error.c.

So, thanks for reporting the missing header, but I think we can
continue using it.  lib/alloca.c is here in case the compiler doesn't
provide it.


| I have also noted quite of a change in the output parser that Bison
| generates, from:
| #if YYDEBUG != 0
| /* YYRLINE[YYN] -- source line where rule number YYN was defined. */
| static const short yyrline[] =
| {
|        0,    80,    82,    84,    86,    87,    88,    89,    90,    91,
|       97,   104,   107,   109,   114,   116,   118,   123,   128,   134,
|      136,   137,   144,   145,   152,   160,   162,   163,   172,   173,
|      176,   177,   187,   196,   197,   206,   207,   210,   213,   214,
|      217,   220,   222,   224,   233,   242,   245
| };
| #endif
| 
| to:
| #if YYDEBUG != 0
| /* YYRLINE[YYN] -- source line where rule number YYN was defined. */
| static const short yyrline[] =
| {
|        0,    80,    80,    82,    82,    82,    82,    82,    82,    82,
|       82,    89,    89,    89,    89,    89,    89,    89,    89,    90,
|       90,    90,    90,    90,    90,   162,    91,   172,    91,   176,
|       91,    91,   196,    91,   206,    91,   210,   213,    91,   217,
|      220,    91,   162,   233,   162,   245,   162
| };
| #endif
| 
| This does not seem right, that the different rules suddenly are defined on
| the same line (I know they are not in the .y sources I used for this
| example).

Thanks for spotting this.  I'll track this down.