Thanks, Akim.
Right, so it is the presence of a destructor that enables this
checking. Might it be worth mentioning in the documentation?
The example in 3.8.7 shows how to use
%destructor { } <character>
it probably confused me. The explanation certainly doesn't tell me
all the ramifications.
-----
Trying a token that does need a destructor I chose a struct term,
which is passed as an lvalue (that is, the entire struct, not a
pointer). Thus struct term does not require a destructor. However,
it contains an optional pointer to a string that must be destroyed and
the token clearly identifies which cases have a pointer. Clearly one
cannot expect Bison to understand such subtlety.
I had to add a variant to the %union (struct term termv) so that those
cases that actually need to be destroyed were identified as such. Of
course this upsets the applecart in a slew of function calls, but
#define termv term
took care of that. Thus the struct yylval that the lexxer sees
remains unchanged.
(Yes I use a struct yylval instead of a union; then incorrect usage
soon results in a null pointer being dereferenced rather than one
struct being mistaken for another.)
On 28 January 2013 13:35, Akim Demaille <[email protected]> wrote:
> Hi John,
>
> If you declared destructors for parsehow and parsecase,
> it is understood as "these symbols allocated memory
> that needs to be reclaimed before the symbol is destroyed".
>
> Bison can "see" that you are not using these symbols
> in the action, so you are certainly leaking them. The
> parser will _not_ reclaim them: %destructor is there
> for error recovery, not to reclaim the memory
> of rhs symbols in an action reduction.
_______________________________________________
[email protected] https://lists.gnu.org/mailman/listinfo/help-bison
