Re: upstreaming SpiderShim customizations to DeflateStringToUTF8Buffer

Yes, absolutely (to both questions)! The implementation in
CharacterEncoding is provided as a convenience to embedders (given that
most text format converter libraries don't support JS's weirdo text
format); if it is inconvenient for embedding then we should definitely
enhance it. If you already have working code, even better.

Cheers,
Terrence

On Fri, May 6, 2016 at 11:20 AM, Myk Melez <[email protected]> wrote:

>
> SpiderShim currently has a custom implementation of
> DeflateStringToUTF8Buffer [1], since neither of the existing ones (the
> public one in CharacterEncoding and a private one in CTypes) does quite
> what it wants, which is to return a partial result if the destination
> buffer runs out of space (CharacterEncoding requires the buffer to have
> enough space [2]) and continue on a bad surrogate (CTypes aborts on a bad
> surrogate [3]).
>
> It seems like it should be possible to refactor all three implementations
> into a single, public one, or at least to upstream the SpiderShim
> customizations into the public implementation in CharacterEncoding (leaving
> the private implementation in CTypes alone). Would the SpiderMonkey team be
> amenable to that? And is this the right forum for such a suggestion, or
> would it be better to file a bug and discuss the proposal there?
>
> -myk
>
> [1]
> https://github.com/mozilla/spidernode/blob/master/deps/spidershim/src/v8string.cc#L455-L538
> [2]
> https://dxr.mozilla.org/mozilla-central/rev/e5a10b/js/public/CharacterEncoding.h#208-213
> [3]
> https://dxr.mozilla.org/mozilla-central/rev/e5a10b/js/src/ctypes/CTypes.cpp#172-177
>
> _______________________________________________
> dev-tech-js-engine mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>