nk_do_edit cut and copy handler passes len as grapheme cluster count to nk_plugin_copy not as count bytes in const char*

[klei1984]

Hello, all demos handle the len parameter of the typedef void(*nk_plugin_copy)(nk_handle, const char*, int len); callback interface as number of bytes in a const char* null terminated C string excluding the nul terminator. But the cut & copy handler code snippet in nk_do_edit() actually passes the count grapheme clusters rendered.

            int b = edit->select_start;
            int e = edit->select_end;

            int begin = NK_MIN(b, e);
            int end = NK_MAX(b, e);
            text = nk_str_at_const(&edit->string, begin, &unicode, &glyph_len);
            if (edit->clip.copy)
                edit->clip.copy(edit->clip.userdata, text, end - begin);

In case of muti-byte encodings like utf-8 this leads to corrupted strings.

In case the nk_plugin_copy callback interface presents text as utf-8 encoded to the user, then the len parameter is currently wrongly set inside nk_do_edit(). In case len should represent glyph count, then multi-glyph or accented grapheme clusters are not supported.

In case it is guaranteed by design that nk_plugin_copy passes utf-8 encoded nul terminated string in its const char* anonymous parameter, then it is proposed to set len to number of bytes in the nul terminated string. In that case most of the existing demo backends would probably handle the len parameter correctly as most simply handle len as count bytes.

[sleeptightAnsiC]

@PavelSharp Just to make sure, your patch from https://github.com/Immediate-Mode-UI/Nuklear/pull/841 fixes this, right (?) (no need to respond, I just wanted you to see this report as it seems the same)