Closed Bug 88411 Opened 23 years ago Closed 12 years ago

ns[C]StringKey doesn't cooperate with strings very well

Categories

(Core :: XPCOM, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: dbaron, Unassigned)

Details

(Keywords: perf)

Attachments

(2 files)

From discussion on IRC and scc's bustage this morning, we've found a few
problems with ns[C]StringKey.

 * The nsAReadableString ctor of nsStringKey doesn't work for non-flat strings
since the promise goes away, freeing the string it points to

 * There is no way to construct an nsCStringKey from an nsACString.

Proposed short-term solution:
 * have 3 constructors for ns[C]StringKey:
     * const PRUnichar*/const char* (existing)
     * nsAFlatString -- works like the current nsAReadableString ctor on
       nsStringKey except without bothering with PromiseFlatString
     * nsAString - a new constructor that just copies the string and owns it.

In the long term we may want to have ns[C]StringKey participate in sharing.
scc just attatched a first attempt at a patch to bug 74726 as attachment 40639 [details] [diff] [review]
r=jag
sr=waterson
Built patch on gcc 2.7.2.3, gcc 3.0, VC6, and MW (Mac).  Ran precheckin tests
fully on Windows and Mac, partially (different parts) on both Linux builds.
giving up ancient string bugs to the new string owner.  jag, you'll want to sort
through these and see which ones still apply and go with or against the
direction in which you intend strings evolve
Assignee: scc → jaggernaut
What is there that needs to be fixing?
Keywords: perf
Assignee: jag → nobody
QA Contact: scc → xpcom
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: