Hello folks,
In SWT there seems to be two approaches to passing String to C land. Does anyone know why there are two ways? (wcsToMbcs vs String.getBytes).
Details:
----------------
1) According to
JNI refefence, One should be using GetStringUTFChars. SWT tools does natively generate correct wrappers that use that. However, JNI uses a modified UTF-8 that removes embedded nulls and only accepts characters up to 3 bytes. (Where as standard UTF-8 allows up to 4 bytes). As a result things like Emojos don't work properly.
This method doesn't seem to be used by SWT calls at all.
2) I observed the other method is to convert String into byte[] array at the Java level. In Converter.java we have:
byte [] wcsToMbcs (.... String string, boolean terminate)
This method will only convert a string up to the first null character, meaning an embedded null-character would cause trouble. But from what I gather, it seems to convert to proper UTF-8 bytes. This method is used in most places.
3) In a few places around the Browser area, I'm seeing an alternative conversion:
byte[] bytes = ((String)value + '\0').getBytes (StandardCharsets.UTF_8); //$NON-NLS-1$
I.e, append a null-terminator manually and convert the whole thing into bytes.
This seems to deal with embedded nulls(?) but native C functions might only read up to the first null character. So it seems that passing length of array might be necessary, but this is never done.
So it sort of comes down to, why was "getBytes()" introduced in addition to the already existing wcsToMbcs()? One could argue because of embedded nulls, but the size is not passed so that doesn't make sense?
If there is no good reason for getBytes() to exist, maybe I should replace those with wcsToMbcs() or replace wcsToMbcs() with getBytes to unify our string conversion approach?
Thank you.
---
Leo Ufimtsev
Software Engineer, Eclipse team.
Toronto, Canada
Red Hat, Inc.
