Re: [Gnash-dev] AMF::encodeElement

[strk]

On Tue, Dec 09, 2008 at 03:56:56PM -0700, Rob Savoye wrote:
> On Tue, Dec 09, 2008 at 01:32:38PM +0100, strk wrote:
> 
> > > This gives a total buffer length of 10 (7+3)
> > > but Element::encode() returns a buffer of 12 bytes.
>  
>   I haven't seen this bug, is it reproduceable with one of the libnet.all
> test cases ? It may be a bug on the encoding for the more complex objects of
> which NetConnection is.

It wasn't, I added the testcase for it.
Another bug is preventing the testcase to reach the point (aborts earlier)
anyway the bug can be reproduced with this:

        Element el;
        el.makeString("connect");
        boost::shared_ptr<Buffer> buf = AMF::encodeElement(el);
        check_equals(buf->size(), 10); // 12 is returned instead

FYI: the abort happens on encoding a NullString ... where a std::string
is attempted to be build from a NULL pointer, still in AMF::encodeElement:

 boost::shared_ptr<Buffer> encstr = AMF::encodeString(el.to_string());

el.to_string() returns 0, ::encodeString expect a std::string, so implicit
construction happens and aborts.
  
> > There's also an AMF::encodeProperty, so maybe we should
> > use AMF_HEADER_SIZE in AMF::encodeElement ?
> 
>   Probably.

> > Should we define a ::getEncodedSize function to
> > scan all componets and tell us ?
> 
>   It's called AMF::totalsize(). It should have been visible in the doxygen
> output. :-)

totalsize() returns a state variable, will be only filled *after* 
the process of encoding, and only while encoding properties (by reading
code, not docs).

What we need is a computation of the required size of a buffer so we
can allocate it once and fill while scanning the elements tree (which
is the current model).

--strk;