Re: calc.at workaround for current test failures

[Paul Eggert]

> From: Frank Heckenbach <address@hidden>
> Date: Tue, 24 Jun 2003 06:27:39 +0200

> Paul Eggert wrote:
> > 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).

Which warnings are these?  To be honest, I'm still skeptical that
anybody still uses K&R C to build new software.

> I can certainly fix such problems that are found by GCC warnings

OK.  For this part of your patch:

-  YYSTYPE yyval = *yy0;
+  YYSTYPE yyval;
+  yyval = *yy0;

the GCC warning doesn't sound correct to me.  But to explain why
we need to go back about 25 years.

I recall that K&R C (i.e., the C language defined by the first edition
of the Kernighan and Ritchie book) did not have structure copying at
all.  However, hardly anybody ever coded to strict K&R C, and glr.c
contains many instances of structure copying.  This patch still has
structure copying, so it is not intended to be portable to compilers
that lack structure copying.

Most people who talk about "K&R C" really mean the language that the
Bell Labs Portable C compiler compiled; let's call that "PCC C".  I
recall that PCC C had structure copying, but you could not initialize
automatic structure variables with initializers, e.g. `auto struct foo
x = {1, 2};' was not allowed.

Perhaps GCC is warning about `YYSTYPE yyval = *yy0;' because the GCC
authors got confused about the difference between K&R C and PCC C.  Or
perhaps they were confused about the difference between supplying an
initial value (like *yy0) and supplying an initializer (something
inside curly braces).  In either case, I suspect that this is a GCC
bug.

I could be proved wrong by someone with access to PCC C.  I haven't
had access to such a beast for several years now, though, so I can't
check this myself.

The other part of your patch:

-                 "Reduced stack %lu by rule #%d; action deferred. "
-                 "Now in state %d.\n",
+        "Reduced stack %lu by rule #%d; action deferred. Now in state %d.\n",

is clearly needed for portablility to PCC C, so I installed it.
Thanks.