gnash-commit
[Top][All Lists]
Advanced

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

Re: [Gnash-commit] gnash ChangeLog libamf/element.cpp libnet/cque....


From: strk
Subject: Re: [Gnash-commit] gnash ChangeLog libamf/element.cpp libnet/cque....
Date: Mon, 7 Apr 2008 22:54:57 +0200

On Mon, Apr 07, 2008 at 02:45:25PM -0600, Rob Savoye wrote:
> strk wrote:
> > On Mon, Apr 07, 2008 at 02:27:54PM -0600, Rob Savoye wrote:
> 
> > Maybe we can add another argument to contain the max size we want the
> > merged buffer to have ?
> 
>   That's handled by the size of the buffer. The buffer's max size for
> the copy is limited by the size of the destination Buffer's size, which
> is initialized at constructor time with a size of totalsize.

Yes, but totalsize is computed by summing size of all buffers to be
merged, which is up to and including the one with size < NETBUFSIZE.
My proposal was to give another limit, to avoid merging all buffers
in the (unlikely?) case that condition is never met.
Current code will just return true if NO buffer size is < NETBUFSIZE
btw...
I guess it's not very important atm since you want to get rid of ::merge
anyway.

> > The important thing is to define ownership of those buffers, which
> > is finding out which class is responsible to get rid of them.
> 
>   Those buffers are all owned by the CQue class, as a buffer is just a
> dequeue of pointers to Buffers.

test_cque.cpp is passing stack-allocated buffers to CQue::push(),
is it safe to assume it's a bug in test_cque.cpp then ?
Just uncomment line 246 of cque.cpp to get rid of merged buffers
and see if your tests work fine.

>   I dislike smart pointers for this kind of thing, and prefer to screw
> with real pointers when manipulating real memory buffers like required
> by a binary protocol. Even C++ is pretty useless when it comes to this
> type of coding.

I disagree but won't start a religious war..

--strk;




reply via email to

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