Re: calc.at workaround for current test failures

[Frank Heckenbach]

Paul Eggert wrote:

> Paul Hilfinger <address@hidden> writes:
> 
> > this near-instantaneous adaptation of the latest version of support
> > software is not standard practice.
> 
> Sorry about that.  Ironically this problem occurred because I was
> responding to Frank Heckenbach's request yesterday to cut a new Bison
> test release, so that he wouldn't have to deal with software support
> issues.

I didn't mean to hurry a release. In fact I'd prefer if my patch of
May 16 would make it into the next release (I put the copyright
assignment in the mail on Jun 6, don't know how long it will take
until it's processed).

> Frank Heckenbach <address@hidden> writes:
> 
> > So, it is possible to download a bison snapshot with the autoconf
> > generated files somewhere? Otherwise I guess I'll have to wait for
> > the next bison release ...
> 
> To help work around this problem I've generated a test release; please
> give it a try.
> 
> ftp://alpha.gnu.org/gnu/bison/bison-1.875b.tar.gz

It works with GLR and locations. So does the archive provided by
Paul Hilfinger.

Some minor comments:

- I think it might be useful if the arguments to the YYLLOC_DEFAULT
  call were parenthesized.

- Could the union yyGLRStackItem and the macro YYRHSLOC be declared
  before the prologue? I'd like to put my locations code in a
  function, so I have to at least declare the function in the
  prologue, so I need the type. It works if I forward-declare the
  union in the prologue and put the function definition (which needs
  the complete union type for YYRHSLOC to work) into the epilogue,
  but it may be nicer not having to do that.

  Well, I see that the union type depends on YYLTYPE, so it might be
  difficult. Perhaps if YYLTYPE is declared in the pre-prologue, the
  union can be declared between the pre- and post-prologue. But if
  that's problematic, at least a forward declaration of the union
  could be added (before the pre-prologue then), I think this
  shouldn't hurt.

- I'm trying to use the parser in an environment where malloc and
  realloc are poisoned (`#pragma GCC poison'); xmalloc and xrealloc
  should be used instead. AFAIK, there's no way around this pragma
  (not even macros), so the use of those functions in glr.c is
  causing a problem. Would it be possible that Bison uses xmalloc
  etc., or some private names which are defined as malloc if not
  set, e.g.:

  #ifndef yymalloc
  #define yymalloc malloc
  #endif

  [...]

  foo = yymalloc (bar);

  (So I could #define yymalloc xmalloc.)

- I'm getting some GCC warnings:

Linux:

parse.c: In function `yyuserMerge':
parse.c:7848: warning: traditional C rejects automatic aggregate initialization
parse.c: In function `yyglrReduce':
parse.c:8322: warning: traditional C rejects string concatenation

DJGPP:

parse.c: In function `yyremoveDeletes':
parse.c:8150: warning: int format, long int arg (arg 3)
parse.c:8150: warning: int format, long int arg (arg 4)
parse.c: In function `yy_reduce_print':
parse.c:8266: warning: int format, long int arg (arg 3)
parse.c: In function `yyglrReduce':
parse.c:8322: warning: int format, long int arg (arg 3)
parse.c:8335: warning: int format, long int arg (arg 3)
parse.c:8335: warning: int format, long int arg (arg 4)
parse.c: In function `yyreportTree':
parse.c:8511: warning: int format, long int arg (arg 7)
parse.c:8511: warning: int format, long int arg (arg 8)
parse.c:8522: warning: int format, long int arg (arg 6)
parse.c:8522: warning: int format, long int arg (arg 7)

The attached patch should fix all of them.

Frank

-- 
Frank Heckenbach, address@hidden
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

glr-warnings.diff
Description: Binary data