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.

Pushed by jandemooij@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/17704f81efef Add JS_NewLatin1String API to create Latin1 strings without copying. r=luke