[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.
Regards,
Sergei.