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)
Core
XPCOM
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.
Reporter | ||
Comment 1•23 years ago
|
||
scc just attatched a first attempt at a patch to bug 74726 as attachment 40639 [details] [diff] [review]
Reporter | ||
Comment 2•23 years ago
|
||
Reporter | ||
Comment 3•23 years ago
|
||
Comment 4•23 years ago
|
||
r=jag
Comment 5•23 years ago
|
||
sr=waterson
Reporter | ||
Comment 6•23 years ago
|
||
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.
Comment 7•22 years ago
|
||
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
Reporter | ||
Comment 8•22 years ago
|
||
See also bug 119745.
Updated•18 years ago
|
Assignee: jag → nobody
QA Contact: scc → xpcom
Updated•12 years ago
|
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.
Description
•