Subj : Re: Retrieving property name in getter and setter functions To : Eric Brueggemann From : Brendan Eich Date : Fri May 09 2003 04:57 pm Eric Brueggemann wrote: > Brendan Eich wrote: > >> >> False -- search for ATOM_NOCOPY, notice that that flag is *not* used >> in the js_InflateStringToBuffer case in js_Atomize. I wonder why you >> thought there was a problem, though. Were you seeing crashes or >> other symptoms of some bug, or were you just reading code? >> > > That appears to only be the case if length < ATOMIZE_BUF_MAX. What appears to be the case? The local buffer is used only to avoid an allocation from the malloc heap for what is a temporary, LIFO-allocated copy of the string, in the case where that string is already atomized -- in the case where js_AtomizeString "hits" an existing atom with that key. Either the char string passed to js_Atomize is short enough to use the local jschar buffer (buf), and js_AtomizeString copies buf only if needed (only if it's not in the atom table, and js_AtomizeString has to add it); or it's long enough that we inflate it into a malloc'd jschar string that will be handed off, via ATOM_NOCOPY, to the atom table on a "miss", and freed at the bottom of js_Atomize on a "hit" or a js_AtomizeString failure). > Perhaps that was an oversight? I'll put together some code to see if I > can demonstrate. What bug are you convinced you've found by inspection, exactly? You originally questioned the assertion about a jsval id being either INT or STRING, but if you're seeing (or just saying ;-) a STRING-tagged id whose chars are dangling or recycled, that's a little different. If you actually have a testcase for a bug symptom, I'm all ears. /be > > > Cheers, > > Eric > .