All the use of JS_NewUCString fn uses a const jschar*, but the implementation takes just a jschar*.
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
Marking Verified -
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.