[Top][All Lists]

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

Re: Bison glr feature request.

From: twlevo
Subject: Re: Bison glr feature request.
Date: Fri, 9 Sep 2005 01:53:47 +0400 (MSD)
User-agent: SquirrelMail/1.4.3a

to other allocator and because of the realloc()
the other allocator must keep track of how many
bytes are allocated with every malloc() done.

if only malloc()/free() is used thats not needed.

that is why it is somewhat easier when there is
no REALLOC used but only MALLOC and FREE.

the realloc() in Bison GLR will always increase
memory usage as can been seen, right ? but the
previous size of the old buffer is not passed on
with the use of realloc().

Hope this is more clear why this feature request.

[wrapping those Bison allocations too to get it faster]

On Thu, September 8, 2005 10:49 pm, Paul Eggert said:
> address@hidden writes:
>> feature request data/glr.c
>> Changing the realloc below in malloc/memcpy/free
>> would make things somewhat easier when wrapping
>> Bison glr memory allocations to another memory
>> subsystem.
> Sorry, I don't follow.  By "wrapping" do you mean defining YYFREE,
> YYMALLOC, and YYREALLOC to some other allocator?
> This is the only invocation of YYREALLOC in the skeleton.  Is your
> point that it'd be easier to wrap if the skeleton never invoked
> YYREALLOC, so that you needn't implement a realloc wrapper?
> I'd rather not have the skeleton do the work of realloc itself.  Aside
> from the extra complexity, rewriting the code to avoid realloc would
> hurt efficiency in the case where realloc can return the original
> pointer, without having to copy the data.
> But I suspect that I'm misunderstanding your request....

see http://www.gnu.org/philosophy/

reply via email to

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