Я работаю со строковыми буферами, и у меня есть некоторые функции, заполняющие эти буферы. У меня также есть несколько модульных тестов, чтобы утверждать, что эти буферы заполнены правильно.
Одна из этих функций использует функцию Windows API
StringCbPrintfA(ansistr , sizeof(ansistr), "%S", wstr);
для преобразования строки Юникода в строку ANSI C.
Суть в том, что в буфере Unicode содержится не завершенная строка wchar, полученная из функции winusb WinUsb_GetDescriptor. Это всегда имеет место с этой функцией winusb. Таким образом, ожидается отсутствующее завершение.
Однако функция StringCbPrintfA по-прежнему преобразует некорректно завершенную широкую строку в правильно завершенную строку ANSI C. Как? В сборке DEBUG все буферы инициализируются с 0xCC во время выполнения Windows. Похоже, что это заставляет StringCbPrintfA правильно завершить строку ANSI.
В сборке RELEASE буферы не инициализируются 0xCC, и StringCbPrintfA НЕ завершает строку ANSI правильно.
Решение очевидно: заполните все рабочие буферы нулями, чтобы обеспечить правильное завершение строки. Тогда все работает в DEBUG и RELEASE.
К сожалению, я хочу защитить код от проблем регрессии, и моя проблема сейчас в том, что мои модульные тесты (с использованием среды Multithreaded-Debug (/ MTd)) успешно выполняются при неправильных обстоятельствах, потому что они получают правильно завершенные строки вПостроение отладки, даже если инициализация нулевого буфера была забыта. Конечно, они не должны проходить.
Теперь мой вопрос:
Как я могу решить этот узел?