Здравствуйте, Alexander G, Вы писали:

AG>Здравствуйте, Sorantis, Вы писали:

S>>А причина запрета МС заключается в том что strlen никогда не завершится (до тех пор пока не встретим access violation) если не найден '\0' . Потому и deprecated.

AG>Не, это не то. Покажите запись за границу буфера через strlen. И секьюрную альтернативу strlen.
легко

void GetUserInput(char *dst_buffer, int max_chars)
{
..
}

void main()
{
char buffer[256+32];
GetUserInput(buffer, 250:
int l = strlen (buffer);
strcat(buffer + l, "stuff less than 32 bytes");

Здравствуйте, Аноним, Вы писали:

AG>>Не, это не то. Покажите запись за границу буфера через strlen. И секьюрную альтернативу strlen.
А>легко

А>

А>void GetUserInput(char *dst_buffer, int max_chars)
А>{
А>..
А>}

А>void main()
А>{
А>char buffer[256+32];
А>GetUserInput(buffer, 250:
А>int l = strlen (buffer);
А>strcat(buffer + l, "stuff less than 32 bytes");
А>

Так виноват-то strcat.

Здравствуйте, Аноним, Вы писали:

А>>>а std::copy для char* некошерно.

КД>>Можно сделать специализацию.

А>Нельзя сделать специализацию.

Вообще говоря, я думал про свою copy, бо решил забить на std::copy после перехода на VS2005

А>>>вообще CString заместо char*.

КД>>А шо это такое — CString? Ни разу за 10 лет не использовал

А>Ну как Вам объяснить. вот у std::basic_string имеются какие-то ....

Да не надо ничего объяснять. Это я так

Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, Аноним, Вы писали:

А>>Упавший модульный тест
AJD>Скорее всего тест отработает нормально

Ну, я по своей наивности полагал, что вызов memset в коде стоит не просто так, а делает что-то полезное и модульные тесты проверют, что тестируемый код делает то, для чего его писали. Но это, конечно случай, редкий и маловероятный.

А>>или замечание на code review это сюрприз?
AJD>Инспектора тоже могут пропустить, особенно если кода много.

А не надо их заставлять ревьюить много кода за малое время, может тогда и польза какая-нибудь от инспекций появится.

Здравствуйте, Аноним, Вы писали:

А>Ну, я по своей наивности полагал, что вызов memset в коде стоит не просто так, а делает что-то полезное и модульные тесты проверют, что тестируемый код делает то, для чего его писали. Но это, конечно случай, редкий и маловероятный.
Просто обычно такой тест короткий, и проблема может не проявится. Ели же тест выполняется часами, в условиях когда оперативки не очень много — тогда да, вероятность проявления очень высока

А>>>или замечание на code review это сюрприз?
AJD>>Инспектора тоже могут пропустить, особенно если кода много.

А>А не надо их заставлять ревьюить много кода за малое время, может тогда и польза какая-нибудь от инспекций появится.

Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, Аноним, Вы писали:

А>>Ну, я по своей наивности полагал, что вызов memset в коде стоит не просто так, а делает что-то полезное и модульные тесты проверют, что тестируемый код делает то, для чего его писали. Но это, конечно случай, редкий и маловероятный.
AJD>Просто обычно такой тест короткий, и проблема может не проявится. Ели же тест выполняется часами, в условиях когда оперативки не очень много — тогда да, вероятность проявления очень высока

Хорошо, допустим, всё так, но ведь и всякие разные functional, regression и прочие stress тесты никто не отменял. По твоим же словам есть большая вероятность заметить эту ошибку.

Однако, я тем не менее, не могу понять, что мешает модульному тесту обнаружить эту проблему. Это ведь не работа с памятью в чистом C через malloc/free. Это memset, вызов которой должен заполнить кусок памяти некоторым значением. Зачем-то же мы меняем состояние этой памяти? Мы ведь ожидаем от этого какой-либо наблюдаемый эффект? Почему тест этого не проверяет?

[snip]

Здравствуйте, Аноним, Вы писали:

А>Однако, я тем не менее, не могу понять, что мешает модульному тесту обнаружить эту проблему. Это ведь не работа с памятью в чистом C через malloc/free. Это memset, вызов которой должен заполнить кусок памяти некоторым значением. Зачем-то же мы меняем состояние этой памяти? Мы ведь ожидаем от этого какой-либо наблюдаемый эффект? Почему тест этого не проверяет?

Тест проверяет наблюдаемый и ожидаемый эффект. Выход за границы буфера и порча других обьектов — это не ожидаемый эффект. Который моджет и не привести к краху, а только некорректной работе.

Здравствуйте, AndrewJD, Вы писали:

AJD>Тест проверяет наблюдаемый и ожидаемый эффект. Выход за границы буфера и порча других обьектов — это не ожидаемый эффект. Который моджет и не привести к краху, а только некорректной работе.

попробуй привести пример кода, где описанная тобой ошибка "перепутали порядок параметров memset" легко была бы гн замечена тестом? Я думаю станет понятнее и тебе и оппоненту...

Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, Аноним, Вы писали:

[snip]

AJD>Тест проверяет наблюдаемый и ожидаемый эффект. Выход за границы буфера и порча других обьектов — это не ожидаемый эффект. Который моджет и не привести к краху, а только некорректной работе.

Я предполагал, что помимо выхода за границы буфера и порчи других объектов будет ещё и отсутсвие нужных действий, что должно сказаться на результатах тестов. Всё таки пример и правда, не помешал бы.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Коваленко Дмитрий, Вы писали:

А>>>а std::copy для char* некошерно.

КД>>Можно сделать специализацию.

А>Нельзя сделать специализацию.

А>

А> 17.3.3.1 Reserved names [lib.reserved.names]

А>1 It is undefined for a C++ program to add declarations or definitions
А> to namespace std or namespaces within namespace std unless otherwise
А> specified. A program may add template specializations for any stan-
А> dard library template to namespace std. Such a specialization (com-
А> plete or partial) of a standard library template results in undefined
А> behaviour unless the declaration depends on a user-defined name of
А> external linkage and unless the specialization meets the standard
А> library requirements for the original template.20)

Положим и так. И что с того? Вряд ли в подавляющем большинстве своём от этого будет
существенный выигрыш.
А>>>вообще CString заместо char*.

КД>>А шо это такое — CString? Ни разу за 10 лет не использовал

А>Ну как Вам объяснить. вот у std::basic_string имеются какие-то size (совпадающий с length) empty (который похож на глагол опустошить), при этом совершенно нет пробразования регистра, регистронезависимого сравнения, возможности _удобно_ получить подстроку с начала/середины/конца, кошерного преобразования "ANSI" <-> Unicode и вообще не понятно, используется ли там подсчёт ссылок, оптимизация малого буфера, или ничего из этого.
А>CString же не обладает вышеозначенными недостатками, и вполне установленный факт, что он использует подсчёт ссылок. Стандарная строка — стандартная, и поэтому велосипеды широко используются.

size/length — ну кто вам виноват что вы не изучали достаточно стандартную библиотеку — вот подучили бы и не путались бы больше. Это же касается и глагола empty. Преобразование регистра — std::use_facet<std::ctype<char> >( yourLocale ).tolower(/*...*/). Что касается преобразований регистра — не забывайте что оно локалезависимое, т.е. в use_facet вы указываете локаль, а CString скорее всего берёт текущую для треда. Вообще не фан CString как и всего MFC в целом. А чем вам кстати не удобен способ с substr методом? Религия не позволяет? С конца надо? rbegin + std algorithms. По поводу кошерного преобразования ANSI -> Unicode, опять же курить фасеты — std::use_facet. А в случае linux приложений или представьте себе что даже QNX бывают — где брать CString? Неужто вешаццо? А представьте себе что существует ещё Borland C++ Builder, Intel C++ compiler и ещё много чего интересного.

С уважением ваш Алекс.