gnash-dev
[Top][All Lists]
Advanced

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

Re: [Gnash-dev] BLOCKER bug in string_table bug


From: strk
Subject: Re: [Gnash-dev] BLOCKER bug in string_table bug
Date: Wed, 6 Feb 2008 11:46:45 +0100

On Tue, Feb 05, 2008 at 09:04:27PM +0100, strk wrote:
> On Tue, Feb 05, 2008 at 08:46:13PM +0100, strk wrote:
> > I think I found a reason for two "Color" strings
> > to be in the index. We are actually creating two at
> > startup time:
> > 
> >         string_table::svt( "color", NSV::PROP_COLOR ) // this is key 9
> >         string_table::svt( "Color", NSV::CLASS_COLOR ) // this is key 106
> > 
> > The mass-load doesn't use "find", and thus fails...
> 
> I made some tests.. both labels (in SWF6, thus case-insensitive)
> are supposed to exist on enumerate.
> 
>       // This one will trace "_global.Color"
>       AsSetPropFlags(_global, "Color", 0, 1);
>       for (var i in _global) trace("_global."+i);
> 
>       // This one will trace "tf.color"
>       tf = new TextFormat();
>       for (var i in tf) trace("tf."+i);
> 
>       // This one will trace "_global.Color" 3 times !!
>       _global.color = 1;
>       _global.cOlor = 2;
>       for (var i in _global) note("_global."+i);

Please forget the result above, will need more careful testing.
The only real problem was in the duplicate comparison value
making lookups unstable (now fixed by dropping PROP_COLOR) and
the wider problem of being unable to use a differently cased
string (when in SWF6 or lower) from the one initially used
(in *any* object). I added a test for the latter in our testsuite.

--strk;





reply via email to

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