Closed Bug 1436065 Opened 2 years ago Closed 2 years ago
Please introduce a Latin1 analog of JS_NewUCString(). Our XPConnect usage of AUTF8String is mostly ASCII, so it's a shame to inflate it to UTF-16 when returning strings to the JS engine. encoding_rs::mem has code for checking if a UTF-8 string has code points only in the Latin1 range and code for converting UTF-8 directly to Latin1. The bug to expose these to C++ is likely going to be bug 1402247.
Just to be clear, you want the no-copy behavior right? (Although JS_NewUCString does copy when it deflates to Latin1). If copying is okay, you could call JS_NewStringCopyN - it has a char* argument that we cast to Latin1Char* internally.
(In reply to Jan de Mooij [:jandem] from comment #1) > Just to be clear, you want the no-copy behavior right? (Although > JS_NewUCString does copy when it deflates to Latin1). I was thinking of no-copy, yes. > If copying is okay, you could call JS_NewStringCopyN - it has a char* > argument that we cast to Latin1Char* internally. I don't really know how performance-sensitive this stuff is. Maybe copying is good enough.
Assignee: nobody → jdemooij
Status: NEW → ASSIGNED
Attachment #8948754 - Flags: review?(luke)
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/17704f81efef Add JS_NewLatin1String API to create Latin1 strings without copying. r=luke
You need to log in before you can comment on or make changes to this bug.