| Summary: | Stray characters appended to labels in ui | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Andrea Antonello <andrea.antonello> |
| Component: | ERCP | Assignee: | ercp.eswt <ercp.eswt-inbox> |
| Status: | NEW --- | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Mobile 5.0 | ||
| Whiteboard: | |||
|
Description
Andrea Antonello
An update on the issue. One of the PhoneME developers was so kind to look into the problem to check if this is a eSWT or phoneME bug (thanks Davy Preuveneers). It looks like the issue in the eRCP tracker is in the right place. It turnes out that in: stringCharData = GetStringChars(env, string); if (ExceptionCheck(env)) return ; stringLength = GetStringLength(env, string); uglstring = convertToNativeString(stringCharData, stringLength, &stringShouldFree); error.error_code = 0; GetStringChars is a JNI method. In that case phoneME returns a non-null terminated pointer to a jchar array (a Unicode string). Then convertToNativeString() transforms this jchar array into an internal representation, but mistakenly assumes that stringCharData is null-terminated. This method is implemented in eSWT and can be found in: http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.ercp/eswt/win/org.eclipse.ercp.swt.core.win/win-native/bindings/impl/TypeConverter.c?root=RT_Project J9 makes sure that all Unicode strings are null-terminated and the eSWT code relies on it. Which is why J9 doesn't have the problem. So to summarize it seems that eSWT wrongly assumes GetStringChars returns null-terminated strings where it should not. Unicode strings are not \0 terminated, whereas UTF-8 strings are (and GetStringChars uses Unicode strings) See sectopm 3.2.4 in: http://java.sun.com/docs/books/jni/html/objtypes.html |