[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: %destructor feedback

From: Joel E. Denny
Subject: Re: %destructor feedback
Date: Thu, 20 Oct 2005 21:01:29 -0400 (EDT)

On Thu, 20 Oct 2005, Paul Eggert wrote:

"Joel E. Denny" <address@hidden> writes:

This thread started on help-bison.  At some point, I CC'ed to
bug-bison. However, it eventually lost that CC and then picked it up
again.  Could this be why you missed messages?

Yes, that's it.  It's such a long thread, though.

That's because I tend to be verbose.

If you're thinking of proposing a coherent patch now,

It'll be a while before I write this patch. I'd be happy to let someone else beat me to it.

perhaps it'd help to summarize it before doing the full work of implementing it.

For whomever ends up writing it, here's a (rather verbose) summary of this thread:

1. The documentation needs to state clearly that, once the bison-generated parser invokes a semantic action, it passes to that semantic action the responsibility for invoking destructors for all associated RHS semantic values. This is true regardless of how the semantic action terminates: usual success, YYACCEPT, YYABORT, or YYERROR.

2. yacc.c needs to be changed for the cases of YYACCEPT and YYABORT to match the above rule.

3. It needs to be decided whether destructors should be invoked automatically for RHS semantic values unmentioned in a semantic action. Here are the arguments against this feature:

a. It breaks the rule in #1 and so it's confusing.

b. It's possible that a user may have stored $5, for example, in a data structure in some other parser or scanner action. Then he might try to destruct it via that data structure in the current semantic action. In other words, his semantic action might destruct $5 without referencing the string `$5'. In that case, bison wouldn't know to leave it alone, and that would lead to a double destructor call. Yes, the user could provide a do-nothing mention of $5 to prevent that, but requiring the user to know to do that is seg fault prone.

c. This feature may make other desirable features impossible in the future. For example, it might be desirable to provide functions that manipulate RHS semantic values and that accept integer parameters to indicate which values. An actual parameter might be a C variable. How can bison compute which value is `mentioned' by yydestruct_rhs_value(x)?

4. If it is decided that the feature in #3 should not be implemented, then perhaps unmentioned RHS semantic values should result in bison-time warnings. There may be special cases (for example, 3.b above) in which it is reasonable not to use a semantic value in an action. In such cases, the user may wish to disable the warning by providing a do-nothing mention of it. Thus, perhaps YYUSE() should be documented as part of the user interface.

5. It would be convenient to provide a function to invoke destructors for all RHS semantic values. Perhaps it should be called yydestruct_rhs()? For example, the user can invoke this before any call on YYABORT or YYACCEPT where he used to expect destructor invocations to be automatic. I am no expert on efficiency, but Wolfgang suggests that yydestruct_rhs() should not be a macro since that could lead to code bloat if it's repeated in numerous semantic actions.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]