help-bison
[Top][All Lists]
Advanced

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

Re: Exception safety of generated C++ parser


From: Oleksii Taran
Subject: Re: Exception safety of generated C++ parser
Date: Fri, 21 Sep 2012 00:38:59 +0300
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1

20.09.12 18:12, Akim Demaille wrote:
> Le 19 sept. 2012 à 20:35, Oleksii Taran a écrit :
>
>> 19.09.12 17:01, Akim Demaille wrote:
>>> Le 13 sept. 2012 à 17:54, Oleksii Taran a écrit :
>>>
>>>> Hello
>>>>
>>>> Does Bison guarantees exception safety in C++ parser, i.e. will it make
>>>> any clean-up and free memory if an exception is thrown on rule action? I
>>>> know about %destructor directive, but it seems irrelevant, since
>>>> destructor code is called only if parser recovers from _syntax_ error.
>>> hi Oleskii,
>>>
>>> Sorry for the delays.
>>>
>>> Yes, I agree that the current implementation is not satisfying on this
>>> regard.  IMHO, the %destructors should be called when an exception is
>>> rised, exactly as if the parsing was ended on a syntax error.  Would that
>>> match your expectations?  Would you be ready to try patches we might
>>> submit?
>>>
>> Yeah, sure, that would be nice, I can help with testing
> Good.  Can you apply patches?  Or would you prefer a tarball?
> Would a git branch do?
>
> I have the attached preliminary patches.  At first, I hoped
> I could reuse the clean up code from YYABORT and YYACCEPT,
> but they do no reclaim the memory of the symbols of the
> current rule (under the assumption that if a rule fires an
> YYABORT, it can manage the memory itself within the rule).
> Besides, yyparse should re-throw the exception, so it is
> really inconvenient to do differently.  Unless one thinks
> it is every better to try-catch the whole yyparse function,
> not just calls to yylex and user actions.  For instance,
> we still would leak if yyerror were to raise an exception,
> or if %initial-action, or if %printer did…  Hum.
>
> So there is quite some duplication here.  I'll see, if this
> patch gives satisfaction, if it can be factored elegantly.
>
> This is against the maint branch.  Comments are *most* welcome.
>

Git branch is preferred, but patches are also okay.

I'll make some testing of your patches in my project, with exceptions
thrown only in rule action code. It will take some time, because I need
to disable all workarounds in my code for memory leaks. I'll try to
provide some feedback on Friday evening.

-- 
Best regards,
Oleksii Taran




reply via email to

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