Our codebase has the conceptual design flaw of representing character
encodings as nsACStrings holding the name of the encoding instead of
having a type-safe representation. This causes ambiguity between
strings that are external protocol text designating an encoding
("label" in spec speak; many labels to one encoding) and internal
strings that have one-to-one mapping to encodings ("name" in spec
speak).In https://bugzilla.mozilla.org/show_bug.cgi?id=encoding_rs , I'm in the process of introducing a type-safe representation for encodings: const mozilla::Encoding* in C++ and Option<&'static encoding_rs::Encoding> in Rust, which have the same memory representation and, thus, are zero-toll bridged between C++ and Rust. (That is, what gets passed around is just a pointer to static. The pointee's fields are only accessed on the Rust side.) The next step (as a multiple separate work items and landings) would be using the type-safe representation throughout the tree. However, using const mozilla::Encoding* in place of char* or nsACString throughout C++ code has JavaScript implications, because encodings occur as arguments (including outparams) in XPIDL methods that are exposed to JS, too. Is it feasible (with reasonably low effort) to introduce a new XPIDL type that is a pointer to a non-refcounted immutable static object in C++ and still gets bridged to JS? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
