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 la
On Thu, May 4, 2017 at 10:08 AM, Henri Sivonen wrote:
> 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?
My question was underspecified. At minimum, the JS bridging shou
On Thu, May 4, 2017 at 3:08 AM, Henri Sivonen wrote:
> 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?
You can certainly have static objects with what amount to dummy
A
On Thu, May 4, 2017 at 4:27 PM, Nathan Froyd wrote:
> On Thu, May 4, 2017 at 3:08 AM, Henri Sivonen wrote:
>> 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?
>
> You
On Thu, May 4, 2017 at 12:32 PM, Henri Sivonen wrote:
> On Thu, May 4, 2017 at 4:27 PM, Nathan Froyd wrote:
>> On Thu, May 4, 2017 at 3:08 AM, Henri Sivonen wrote:
>>> Is it feasible (with reasonably low effort) to introduce a new XPIDL
>>> type that is a pointer to a non-refcounted immutable st
5 matches
Mail list logo
