JS_NewUCString fn should take a const jschar*

VERIFIED INVALID

Status

()

VERIFIED INVALID
18 years ago
17 years ago

People

(Reporter: skasinathan, Assigned: rogerl)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
All the use of  JS_NewUCString fn uses a const jschar*, but the implementation 
takes just a jschar*.

Comment 1

18 years ago
cc'ing Brendan on this one -
What's the motivation behind this bug?  JS_NewString and JS_NewUCString both
entail handing of memory (at bytes and chars, respectively) to the JS engine,
which is theoretically free to modify that memory, and is definitly "free"
(sorry, pun) to free() it when the string becomes garbage -- note that free()
takes a void *, not a const void *.  A pointer to such memory should not be
const; the lack of const implies ownership transfer.

It's true that users of JS_GetStringChars should have only const access to the
character memory; ditto JS_GetStringBytes.  Those are the APIs to question.  But
I don't see a bug with JS_NewString and JS_NewUCString, which should continue to
eschew const, to signify memory ownership transfer.

/be
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID

Comment 3

18 years ago
Marking Verified - 
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.