[Top][All Lists]
[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;