[Top][All Lists]

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

Re: GLR C++ Parser leaks Memory

From: Sergei Steshenko
Subject: Re: GLR C++ Parser leaks Memory
Date: Thu, 8 Nov 2012 13:33:19 -0800 (PST)

----- Original Message -----
> From: Roland Kaminski <address@hidden>
> To: Akim Demaille <address@hidden>
> Cc: address@hidden
> Sent: Thursday, November 8, 2012 11:21 PM
> Subject: Re: GLR C++ Parser leaks Memory
> On Thursday, November 08, 2012 09:21:01 PM you wrote:
>>  Le 8 nov. 2012 à 17:46, Roland Kaminski a écrit :
>>  > Hi all,
>>  Hi Roland,
>>  > I am using bison 2.6.5 and discovered that the GLR parser leaks memory
>>  > when
>>  > exceptions are used. I used the glr.cc skeleton and want to throw an
>>  > exception after a certain amount of syntax errors. The memory is 
> leaked
>>  > by the glr-stack itself and not by any of my semantic values (they 
> don't
>>  > need destruction).
>>  > 
>>  > This is no show-stopper for me but it would be nice if the generated
>>  > parser
>>  > were exception safe. I attached some valgrind output that should 
> indicate
>>  > where the memory is leaked. Also note that if I switch to the larl1.cc
>>  > skeleton, no memory is leaked. (But I cannot parse some input then.)
>>  glr.cc is a hack.  In a perfect world, it would be rewritten from scratch
>>  (today, it's a wrapper around glr.c).  As there does not seem to be 
> enough
>>  demand for a genuine glr.cc, it is not planned to write one.
> Yes, I looked into the code right after writing the mail and figured out the 
> same. Looks like there is not much C++ in there.
>>  Help would be most welcome ;)
> I have some experience with parser generators but no time for such a project 
> at the moment. Maybe after I am finished with my current workload. :)
> Regards, Roland

Why to write a C++ parser ? As a 'bison' demo ?

Because for practical uses there is 'gcc' and LLVM.


reply via email to

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