Reported by nishimotz on 2013-05-14 13:54
Memory allocation issue in ime.cpp causes irrelevant garbage announces at Windows desktop operations, when IMM-based Japanese input methods are active, such as Google Japanese IME or ATOK.
As in the patch below, malloc(len) is obtaining wrong size of cand_str buffer, and the string may not be initialized if there are no candidates.
diff --git a/nvdaHelper/remote/ime.cpp b/nvdaHelper/remote/ime.cpp
index deeca61..fb41ab3 100644
--- a/nvdaHelper/remote/ime.cpp
+++ b/nvdaHelper/remote/ime.cpp
@@ -326,7 +326,19 @@ static bool handleCandidates(HWND hwnd) {
}
/* Concatenate currently shown candidates into a string */
+#if 0
WCHAR* cand_str = (WCHAR*)malloc(len);
+#else
+ size_t buflen = 1; // make sure len != 0
+ for (DWORD n = list->dwPageStart; n < pageEnd; ++n) {
+ DWORD offset = list->dwOffset[cand = (WCHAR*)(((char*)list) + offset);
+ size_t clen = wcslen(cand);
+ buflen += (clen + 1) * sizeof(WCHAR);
+ }
+ WCHAR* cand_str = (WCHAR*)malloc(buflen);
+ cand_str[0](n];
+ WCHAR*) = '\0';
+#endif
WCHAR* ptr = cand_str;
for (DWORD n = list->dwPageStart, count = 0; n < pageEnd; ++n) {
DWORD offset = list->dwOffset[n];
Reported by nishimotz on 2013-05-14 13:54
Memory allocation issue in ime.cpp causes irrelevant garbage announces at Windows desktop operations, when IMM-based Japanese input methods are active, such as Google Japanese IME or ATOK.
As in the patch below, malloc(len) is obtaining wrong size of cand_str buffer, and the string may not be initialized if there are no candidates.