Re: calc.at workaround for current test failures

[Frank Heckenbach]

Paul Eggert wrote:

> > From: Frank Heckenbach <address@hidden>
> > Date: Fri, 20 Jun 2003 00:20:35 +0200
> 
> > > > - 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 ...)?
> 
> Could you please do it?  That would save me a bit of time.

Patch attached.

Besides YYSTACK_ALLOC and YYSTACK_FREE (copied from yacc.c), glr.c
also needs permant allocation. I used the macro names YY_MALLOC,
YY_REALLOC and YY_FREE, is this ok?

I'm also doing it for abort (YY_ABORT) since programs may like to
provide their own version.

> > > 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).
> 
> Surely GCC gives these warnings only if you ask for them.  And the
> only reason that you'd ask for them is because you want to support K&R
> C.  But glr.c doesn't support K&R C, so the warnings are actually
> useful: they are indicating to you that you are doing something that
> isn't supported.
> 
> > which C89 features does glr.c require exactly?
> 
> Sorry, I don't know; I haven't had time to go through glr.c and look
> for C89isms.  (Possibly there aren't any, other than the ones that
> you've identified; but I doubt it.)  If you'd like to take on the job
> of maintaining K&R C support for glr.c (and cleaning up after other
> maintainers' messes when they mess it up), please feel free, but I
> suspect that there would be better uses of your time.  Nobody uses K&R
> C any more outside of museums.

Apparently some people still care, otherwise these warnings wouldn't
have been added in GCC recently (they weren't present in older GCC
versions AFAIK).

I don't have a K&R compiler (is there a free one available?). I can
certainly fix such problems that are found by GCC warnings (also
possibly new warnings in future GCC versions) or reported by users.
I understand that these will probably be minor issues such as these,
no fundamental limitations, so I think it's easy enough to fix them
when they are found. Therefore I'm including the respective patch
again.

Frank

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

glr-knr.diff
Description: Binary data

glr-macros.diff
Description: Binary data