Re: Misc. minor bison 1.33 bugs and annoyances patched

[Bruce Lilly]

Akim Demaille wrote:
> 
> | Hello,
> 
> Hi!  Thanks for the patch.  But one first problem is that we take
> single task patches, yours addresses different issues.

Aside from the yydebug comment, these are all compilation issues
related to the output file produced by bison.

>  Also, did you
> sign the papers for the FSF and specifically Bison?

Papers? What papers?  Is this some new procedure designed to
kill the open source movement?

> 
> | The attached patch fixes the following minor bugs and
> | (some not-so-minor) annoyances in bison 1.33 (some of
> | which also afflicted earlier versions):
> |
> | 1. use of ugly and error-prone pointer casts is no longer
> |    required with YYPURE if YYPARSE_PARAM_PTR_TYPE
> |    is defined (see revised documentation for details).
> 
> I very much agree with your intention here, but there are other major
> changes in Bison, and first of all, I want them to be finished before
> starting any other deep change.  You will certainly argue that your
> patch is not profound, but it is: it is part of things that must be
> carefully thought in conjunction with multiple language output etc.

The patch should work with K&R C, ANSI C and C++.  What else
did you have in mind?

> I plan to move to a Bison parser for the .y files, which might render
> these obscure CPP macros completely obsolete.

Well, the output from bison, no matter how it is generated,
still needs to be compiled. In the case of reentrant parsers,
it is desirable to have the argument explicitly typed
correctly so one can write ruleset action code like:
        x->a = x->b + x->c % x->d;
instead of
        ((struct foo *)x)->a = ((struct foo *)x)->b + ((struct foo *)x)->c % 
((struct foo *)x)->d;
as the latter gets quite tedious for large grammars.

> | 2. explanation of yydebug for "--akim".
> 
> I understood this bit since, and I'm still shocked it works!  I find
> this incredibly ugly!  I'll adjust the comment, thanks for the impetus.

It's not such a big deal; it beats forcing the caller to
define it.  And if the -p option is used multiple parsers
can have debug mode set independently.
 
> | 3. avoided compiler diagnostics for bison.simple regarding
> |    possible loss of information due to integral type
> |    promotion.
> 
> The idea is OK, but then, please work on the CVS version of Bison, as
> 1.33 is basically dead (only maintenance).

Has bison.simple changed so much in the CVS version that the patch
cannot be applied?  There's a related small change to output.c,
but it's so simple I'd be really surprised if it couldn't be
applied to the current development version (esp. as 1.33 is the
latest release).
 
> | 4. avoided "constant conditional" compiler diagnostics for
> |    bison.simple due to useless do - while (0) in macros.
> 
> This is on purpose.

I understand that one might care about being able to write
        YYDPRINTF(foo);
instead of
        YYDPRINTF(foo)
and the patch provides for that without the annoying compiler
complaints (which appear in every bison-generated parser).

> 
> | 5. proper prototype declaration for __STDC__ as well as
> |    for __cplusplus.
> 
> This is interesting.  I would apply it to CVS Bison.

Another compiler diagnostic issue; several similar ones
were fixed between 1.28 and 1.33, but the yyparse prototype
seems to have been missed.

Best regards,
  Bruce Lilly