Closed Bug 288786 Opened 19 years ago Closed 19 years ago

Add BeginWriting equivalent to frozen string API


(Core :: XPCOM, enhancement, P1)






(Reporter: benjamin, Assigned: darin.moz)



(Whiteboard: [bsmedberg-APIs])


(1 file)

We need to add an equivalent for BeginWriting to the frozen string API for gecko
1.8.  Darin, if you won't have time for this reassign it back to me.
Flags: blocking-aviary1.1+
Whiteboard: [bsmedberg-APIs]
Yeah, this is something I really want to do as well.

This means adding NS_C?StringGetMutableData (or something like that) to the
frozen XPCOM exports.
Severity: normal → enhancement
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta2
We may also want a way to set the string buffer length.
(In reply to comment #2)
> We may also want a way to set the string buffer length.

Why not make that a single function?
Yes, that is exactly my plan.  Here's my suggestion:

  NS_StringGetMutableData(nsAString &aStr,
                          PRUint32 aDataLength,
                          PRUnichar **aData);

The idea here is that you could pass PR_UINT32_MAX as aDataLength to indicate
that you want the current length of the string.  The length of the data buffer
returned by aData is indicated by the return value of this function.  If the
function fails because it could not allocate memory, then aData is set to null,
and the function returns 0 or maybe PR_UINT32_MAX (not sure about what the
function should return if unable to allocate memory).

At any rate, I'm leaning toward this function signature over one that returns
the buffer itself for consistency (somewhat) with NS_StringGetData.

Sounds fine, and it should return 0 if allocation was unsuccessful.
Here's what I have so far:

 * NS_StringGetMutableData
 * This function provides mutable access to a string's internal buffer.  It
 * returns a pointer to an array of characters that may be modified.  The
 * returned pointer remains valid until the string object is passed to some
 * other string function.
 * Optionally, this function may be used to resize the string's internal
 * buffer.  The aDataLength parameter specifies the requested length of the
 * string's internal buffer.  By passing some value other than PR_UINT32_MAX,
 * the caller can request that the buffer be resized to the specified number of
 * characters before returning.  The caller is not responsible for writing
 * null-terminator.
 * @param aStr          abstract string reference
 * @param aDataLength   number of characters to resize the string's internal
 *                      buffer to or PR_UINT32_MAX if no resizing is needed
 * @param aData         out param that upon return holds the address of aStr's
 *                      internal buffer or null if the function failed
 * @return              number of characters or zero if the function failed
  (nsAString &aStr, PRUint32 aDataLength, PRUnichar **aData);

If you see any problems with this, please let me know.
Attached patch v1 patchSplinter Review
Attachment #179628 - Flags: review?(cbiesinger)
Comment on attachment 179628 [details] [diff] [review]
v1 patch

+  return begin.size_forward();

that does not include the null terminator, right?

(hrm, this file has a lot of functions that only differ in data type. could we
use some template functions to avoid code duplication, at least source-wise?
not for this bug, certainly)
Attachment #179628 - Flags: review?(cbiesinger) → review+
Attachment #179628 - Flags: superreview?(dbaron)
Comment on attachment 179628 [details] [diff] [review]
v1 patch

>Index: stub/nsXPComStub.cpp
>     &NS_Alloc_P,
>     &NS_Realloc_P,
>     &NS_Free_P,
>     &NS_StringContainerInit2_P,
>-    &NS_CStringContainerInit2_P
>+    &NS_CStringContainerInit2_P,
>+    &NS_StringGetMutableData,
>+    &NS_CStringGetMutableData

Any reason these don't use _P ?

Other than that, sr=dbaron.
Attachment #179628 - Flags: superreview?(dbaron) → superreview+
whoops.. yes!  thank you for catching that mistake.
Comment on attachment 179628 [details] [diff] [review]
v1 patch

This is a new API that would be nice to have in the developer preview.
Attachment #179628 - Flags: approval1.8b2?
Comment on attachment 179628 [details] [diff] [review]
v1 patch

Attachment #179628 - Flags: approval1.8b2? → approval1.8b2+
Closed: 19 years ago
Resolution: --- → FIXED
*** Bug 242577 has been marked as a duplicate of this bug. ***
Component: String → XPCOM
You need to log in before you can comment on or make changes to this bug.