Re: calc.at workaround for current test failures

[Paul Eggert]

> 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.

> > 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.