Re: calc.at workaround for current test failures

[Frank Heckenbach]

Paul Eggert wrote:

> Frank Heckenbach <address@hidden> writes:
> 
> >  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).
> 
> It's not processed yet, unfortunately.  By "patch of May 16" I assume
> you mean the revised no-default-precedence patch in
> <http://mail.gnu.org/archive/html/bison-patches/2003-05/msg00017.html>.

Yes.

> > - I think it might be useful if the arguments to the YYLLOC_DEFAULT
> >   call were parenthesized.
> 
> They seem parenthesized already in glr.c -- perhaps I'm missing
> something?

In my copy it says (line 708):

      YYLLOC_DEFAULT (*yylocp, yyvsp - yyrhslen, yyrhslen);

It should be:

      YYLLOC_DEFAULT ((*yylocp), (yyvsp - yyrhslen), yyrhslen);

I suppose you mean the macro definition. Yes, generally, parentheses
are put in macro definitions. But since in this case the macro call
is generated by bison and the macro is (often) provided by the user,
it might be useful to add the parentheses in the call.

> > - 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
> 
> That makes a lot of sense to me.  yacc.c already uses YYSTACK_ALLOC
> and YYSTACK_FREE for malloc and free, though those names suggest a
> stack rather than a heap.

Are you doing it, or should I make a patch (when my assignment is
processed, that is ...)?

> > parse.c:7848: warning: traditional C rejects automatic aggregate 
> > initialization
> > parse.c:8322: warning: traditional C rejects string concatenation
> 
> glr.c assumes C89 or better.  I'd rather not worry about supporting
> K&R C in glr.c; K&R is obsolete and supporting it takes away time from
> more important things.

It's just that newer versions of GCC give those warnings, and I like
warning-free compiles (especially if it's so easy to fix as in this
case).

BTW, which C89 features does glr.c require exactly?

> > parse.c:8150: warning: int format, long int arg (arg 3)
> 
> Thanks for reporting that problem.  I fixed it with the following
> patch, which I wrote without looking at your patch (I can't wait
> for your copyright papers to come in....).

I thought such trivial changes were non-copyrightable, anyway. ;-)
Anyway, your changes are equivalent to mine.

Frank

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