Re: calc.at workaround for current test failures

[Frank Heckenbach]

Paul Eggert wrote:

> > From: Frank Heckenbach <address@hidden>
> > Date: Tue, 24 Jun 2003 06:27:39 +0200
> 
> > 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?

warning: traditional C rejects automatic aggregate initialization

(with `-Wtraditional')

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

But is the above structure copying or an initializer? I'd have
thought the latter (while the proposed change would be structure
copying).

> Perhaps GCC is warning about `YYSTYPE yyval = *yy0;' because the GCC
> authors got confused about the difference between K&R C and PCC C.

Well, the warning doesn't actually talk about "K&R", just
"traditional" C. Perhaps they really mean PCC C or the intersection
of features of several traditional compilers.

Anyway, is there a problem with making that change? It doesn't
really make the source more complicated (and the object code should
be just the same).

Frank

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