Hi,
It's probably not allowed to use %lc format.
Both %c and %lc produce the same trace output: trace:msvcp90:MSVCP_basic_string_wchar_assign_cstr_len 0x32fc20 L"abc" 3 trace:msvcp90:MSVCP_basic_string_wchar_append_len_wchar 0x32fc20 0 z trace:msvcp90:MSVCP_basic_string_wchar_c_str 0x32fc20 trace:msvcp90:MSVCP_basic_string_wchar_append_len_wchar 0x32fc20 2 z trace:msvcp90:MSVCP_basic_string_wchar_c_str 0x32fc20
Should I send a patch with %c instead?
The "l" modifier most likely is ignored and will print correct result only for ASCII symbols.
Regards, Vincas M.
On 04/20/2011 05:24 PM, Piotr Caban wrote:
Hi,
On 04/18/11 23:53, Vincas Miliūnas wrote:
My remark: (The method is implemented by reusing existing code) this->size+count<this->size is the same as count< 0 and throwing a "string too long" exception in that case is not semantic.
count is an unsigned variable so it cannot be smaller then 0. My intention was to make sure there's no overflow. This check is not needed because MSVCP_basic_string_char_npos-this->size <= count already makes sure this->size+count has small enough value.
+basic_string_wchar* __thiscall MSVCP_basic_string_wchar_append_len_wchar(
basic_string_wchar *this, size_t count, wchar_t c)+{
- TRACE("%p %lu %lc\n", this, (unsigned long)count, c);
It's probably not allowed to use %lc format.
Cheers, Piotr