Сообщение Непонятное поведение функции _tcsncpy_s из tchar.h от 06.05.2015 19:26
Изменено 06.05.2015 19:39 MASReady
Доброго времени суток!
Имеем: Windows 7 x64, Visual Studio 2010 и консольный проект со следующим кодом:
в результате работы кода получаем следующее содержимое BUF:
[0]='0',[1]='1',[2]='2',[3]='3',[4]='4',[5]='5',[6]='6',[7]='7',[8]='8',[9]='9',
[10]=0x0000,[11]=0xfefe,[12]=0xfefe,[13]=0xfefe,[14]=0xfefe,
если значение параметра 2 поменять с 15 на 50, то символом с кодом 0xfefe будут залиты все оставшиеся элементы массива BUF
в отладке можно зайти внутрь этой функции(_tcsncpy_s), и увидеть следующее:
причем она все правильно делает до предпоследней строки(_FILL_STRING(_DEST, _SIZE, _SIZE — available + 1)), которая и забивает остаток символами с кодом 0xfefe
что это за,мягко говоря, странное поведение???
может я чего-то не понял?
если буфер BUF сделать размером, например, 20000 то, и указать во втором параметре вызова _tcsncpy_s — 20000, то она забъет весь остаток символами 0xfefe, что мягко говоря нехорошо отразится на производительности софта.
Но главный вопрос, все-таки, ЗАЧЕМ ОНА ЭТО ДЕЛАЕТ???
Имеем: Windows 7 x64, Visual Studio 2010 и консольный проект со следующим кодом:
#include <tchar.h>
int _tmain(int argc, _TCHAR* argv[])
{
TCHAR BUF[50]=_T("");
LPCTSTR ADD=_T("0123456789");
//параметры: 1-буфер куда копируем,
// 2-размер буфера в параметре 1(в символах: в нашем случае TCHAR(2 байта)),
// 3-буфер откуда копируем,
// 4-количество элементов (в символах: в нашем случае TCHAR(2 байта))
// которые нужно скопировать из буфера указанного в параметре 3 в буфер указанный в параметре 1
errno_t etRes=_tcsncpy_s(BUF,15,ADD,10);
return 0;
}
в результате работы кода получаем следующее содержимое BUF:
[0]='0',[1]='1',[2]='2',[3]='3',[4]='4',[5]='5',[6]='6',[7]='7',[8]='8',[9]='9',
[10]=0x0000,[11]=0xfefe,[12]=0xfefe,[13]=0xfefe,[14]=0xfefe,
если значение параметра 2 поменять с 15 на 50, то символом с кодом 0xfefe будут залиты все оставшиеся элементы массива BUF
в отладке можно зайти внутрь этой функции(_tcsncpy_s), и увидеть следующее:
_FUNC_PROLOGUE
errno_t __cdecl _FUNC_NAME(_CHAR *_DEST, size_t _SIZE, const _CHAR *_SRC, size_t _COUNT)
{
_CHAR *p;
size_t available;
if (_COUNT == 0 && _DEST == NULL && _SIZE == 0)
{
/* this case is allowed; nothing to do */
_RETURN_NO_ERROR;
}
/* validation section */
_VALIDATE_STRING(_DEST, _SIZE);
if (_COUNT == 0)
{
/* notice that the source string pointer can be NULL in this case */
_RESET_STRING(_DEST, _SIZE);
_RETURN_NO_ERROR;
}
_VALIDATE_POINTER_RESET_STRING(_SRC, _DEST, _SIZE);
p = _DEST;
available = _SIZE;
if (_COUNT == _TRUNCATE)
{
while ((*p++ = *_SRC++) != 0 && --available > 0)
{
}
}
else
{
_ASSERT_EXPR((!_CrtGetCheckCount() || _COUNT < _SIZE), L"Buffer is too small");
while ((*p++ = *_SRC++) != 0 && --available > 0 && --_COUNT > 0)
{
}
if (_COUNT == 0)
{
*p = 0;
}
}
if (available == 0)
{
if (_COUNT == _TRUNCATE)
{
_DEST[_SIZE - 1] = 0;
_RETURN_TRUNCATE;
}
_RESET_STRING(_DEST, _SIZE);
_RETURN_BUFFER_TOO_SMALL(_DEST, _SIZE);
}
_FILL_STRING(_DEST, _SIZE, _SIZE - available + 1);
_RETURN_NO_ERROR;
}
причем она все правильно делает до предпоследней строки(_FILL_STRING(_DEST, _SIZE, _SIZE — available + 1)), которая и забивает остаток символами с кодом 0xfefe
что это за,мягко говоря, странное поведение???
может я чего-то не понял?
если буфер BUF сделать размером, например, 20000 то, и указать во втором параметре вызова _tcsncpy_s — 20000, то она забъет весь остаток символами 0xfefe, что мягко говоря нехорошо отразится на производительности софта.
Но главный вопрос, все-таки, ЗАЧЕМ ОНА ЭТО ДЕЛАЕТ???
Непонятное поведение функции _tcsncpy_s из tchar.h
Доброго времени суток!
Имеем: Windows 7 x64, Visual Studio 2010 и консольный проект со следующим кодом:
в результате работы кода получаем следующее содержимое BUF:
[0]='0',[1]='1',[2]='2',[3]='3',[4]='4',[5]='5',[6]='6',[7]='7',[8]='8',[9]='9',
[10]=0x0000,[11]=0xfefe,[12]=0xfefe,[13]=0xfefe,[14]=0xfefe,
если значение параметра 2 поменять с 15 на 50, то символом с кодом 0xfefe будут залиты все оставшиеся элементы массива BUF
в отладке можно зайти внутрь этой функции(_tcsncpy_s), и увидеть следующее:
причем она все правильно делает до предпоследней строки(_FILL_STRING(_DEST, _SIZE, _SIZE — available + 1)), которая и забивает остаток символами с кодом 0xfefe
что это за,мягко говоря, странное поведение???
может я чего-то не понял?
если буфер BUF сделать размером, например, 20000 то, и указать во втором параметре вызова _tcsncpy_s — 20000, то она забъет весь остаток символами 0xfefe, что мягко говоря нехорошо отразится на производительности софта.
Но главный вопрос, все-таки, ЗАЧЕМ ОНА ЭТО ДЕЛАЕТ???
p.s. Может, конечно, кто-то, в отладочных целях, для себя оставил и забыл убрать, но ....
Имеем: Windows 7 x64, Visual Studio 2010 и консольный проект со следующим кодом:
#include <tchar.h>
int _tmain(int argc, _TCHAR* argv[])
{
TCHAR BUF[50]=_T("");
LPCTSTR ADD=_T("0123456789");
//параметры: 1-буфер куда копируем,
// 2-размер буфера в параметре 1(в символах: в нашем случае TCHAR(2 байта)),
// 3-буфер откуда копируем,
// 4-количество элементов (в символах: в нашем случае TCHAR(2 байта))
// которые нужно скопировать из буфера указанного в параметре 3 в буфер указанный в параметре 1
errno_t etRes=_tcsncpy_s(BUF,15,ADD,10);
return 0;
}
в результате работы кода получаем следующее содержимое BUF:
[0]='0',[1]='1',[2]='2',[3]='3',[4]='4',[5]='5',[6]='6',[7]='7',[8]='8',[9]='9',
[10]=0x0000,[11]=0xfefe,[12]=0xfefe,[13]=0xfefe,[14]=0xfefe,
если значение параметра 2 поменять с 15 на 50, то символом с кодом 0xfefe будут залиты все оставшиеся элементы массива BUF
в отладке можно зайти внутрь этой функции(_tcsncpy_s), и увидеть следующее:
_FUNC_PROLOGUE
errno_t __cdecl _FUNC_NAME(_CHAR *_DEST, size_t _SIZE, const _CHAR *_SRC, size_t _COUNT)
{
_CHAR *p;
size_t available;
if (_COUNT == 0 && _DEST == NULL && _SIZE == 0)
{
/* this case is allowed; nothing to do */
_RETURN_NO_ERROR;
}
/* validation section */
_VALIDATE_STRING(_DEST, _SIZE);
if (_COUNT == 0)
{
/* notice that the source string pointer can be NULL in this case */
_RESET_STRING(_DEST, _SIZE);
_RETURN_NO_ERROR;
}
_VALIDATE_POINTER_RESET_STRING(_SRC, _DEST, _SIZE);
p = _DEST;
available = _SIZE;
if (_COUNT == _TRUNCATE)
{
while ((*p++ = *_SRC++) != 0 && --available > 0)
{
}
}
else
{
_ASSERT_EXPR((!_CrtGetCheckCount() || _COUNT < _SIZE), L"Buffer is too small");
while ((*p++ = *_SRC++) != 0 && --available > 0 && --_COUNT > 0)
{
}
if (_COUNT == 0)
{
*p = 0;
}
}
if (available == 0)
{
if (_COUNT == _TRUNCATE)
{
_DEST[_SIZE - 1] = 0;
_RETURN_TRUNCATE;
}
_RESET_STRING(_DEST, _SIZE);
_RETURN_BUFFER_TOO_SMALL(_DEST, _SIZE);
}
_FILL_STRING(_DEST, _SIZE, _SIZE - available + 1);
_RETURN_NO_ERROR;
}
причем она все правильно делает до предпоследней строки(_FILL_STRING(_DEST, _SIZE, _SIZE — available + 1)), которая и забивает остаток символами с кодом 0xfefe
что это за,мягко говоря, странное поведение???
может я чего-то не понял?
если буфер BUF сделать размером, например, 20000 то, и указать во втором параметре вызова _tcsncpy_s — 20000, то она забъет весь остаток символами 0xfefe, что мягко говоря нехорошо отразится на производительности софта.
Но главный вопрос, все-таки, ЗАЧЕМ ОНА ЭТО ДЕЛАЕТ???
p.s. Может, конечно, кто-то, в отладочных целях, для себя оставил и забыл убрать, но ....