wcstok_s() vs strtok_s()

// определения:

char *strtok_s(
   char *strToken,
   const char *strDelimit,
   char **context
);
wchar_t *wcstok_s(
   wchar_t *strToken,
   const wchar_t *strDelimit,
   wchar_t **context
);

// реализация здесь crt_strtok_s.c, либо где-то в библиотеке CRT "болтается"

Вопрос: что будет, если 3-й аргумент будем устанавливать в NULL ?
обе функции безопасный аналог strtok и wcstok, но с дополнительными костылями в виде 3-го, на мой взгляд не нужного аргумента.
Во всяком случае, могли бы его запихнуть внутрь функции, а не делать дополнительный параметр.
Мелочь, но всё равно раздражает

Специально для тебя в MSDN есть табличка: http://msdn.microsoft.com/en-us/library/ftsafwz3%28v=vs.80%29.aspx
Третий параметр нужен для потокобезопасности в многопоточном приложении.

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

На самом деле это нужно даже не для потокобезопасности.
Обычная strtok использует статический указатель, поэтому не позволяет производить разбор двух и более строк в параллель (даже в одном потоке).

В принципе да, но в одном потоке это по крайней мере вручную контролировать можно.
А с несколькими потоками проблемы серьёзные будут.

Всё что написано выше в этой теме истинная правда.
Но в большинстве случаев всё таки не требуется производнить разбор 2-х и более строк, также как справедливо утвреждение, что не каждое создаваемое приложение будет многопоточным.
Поэтому я лично в большинстве случаев использовал бы strtok и wcstok, вместо strtok_s и wcstok_s.
Только вот при их использовании, компилятор начинает ругаться и выдавать предупреждения, а отключать их принудительно лень.
Создаётся ощущение, что компилятор от Microsoft как бы намекает программисту, что он не знает что делает и творит. Что вызывает большие сомнения. Вообще это касается не только данного случая. Программисты от индусско-китайского Микрософта любят создавать по 10 аналогов одной и той же функции - на все случаи жизни, вместо того чтобы просто изначально писать 1 универсальную, работоспособную и при любых ситуациях.

Программисты от Микрософта в первую очередь пекуться о соответствии своих библиотек Стандарту, а так же об индусско-китайских кодерах, которые то и дело забывают о безопасности. Если тебя не надо предупреждать о потенциально опасных Стандартных функциях, прими мои поздравления, ибо подавляющее большинство грамотных программистов продолжают писать код типа

int *pArray = malloc(numElements * sizeof(int));

и при этом уверены, что тут ошибки нет и быть не может. Кстати, вероятно многие из небезопасных Стандартных С-функций в новом Стандарте будут объявлены устравшими.

Кстати, а какая тут может быть ошибка?
Кроме уже имеющегося отсутствия приведения типа?
Хотя надо сказать, явное приведение может замаскировать куда более опасные ошибки.

Цитата Qraizer @ 16.02.11, 15:19

и при этом уверены, что тут ошибки нет и быть не может

Я может чего не понял... А где тут ошибка?
За исключением того что malloc() void* возвращает, т.е. приведение типов не помешает (хотя для Си не обязательно).

Сообщение отредактировано: cppasm - 16.02.11, 15:51

если бы два потока одновремен но вызывали функцию malloc, куча могла бы быть повреждена. Если я правильно понял =)

С чего бы это?

Цитата amk @ 16.02.11, 15:48

Кроме уже имеющегося отсутствия приведения типа?

В С это не ошибка, а в Плюсах граммотные программисты не будут использовать malloc().
Ошибка в другом. Кстати, эту ошибку эксплуатировали эксплойты в Adobe Flash Player.

хех.. идея ясна и если вы её повернули таким углом, то конечно сложно не согласиться.
Но.

Лучше сделать изначально безопасную функцию, чем:
А) 1 безопасную
Б) 2-ю опасную
В) 3-ю для однобайтовых символов
Г) 4-ю для 2-х байтовых символов, это ещё кстати от Оси зависеть
Д) 5-ю для так называемых широких символов, с поддеркжой Unicode
Е) 6-ю как знать для OLE строк
7-ю для BSTR строк
З) 8-ю как знать для чего ещё
И) у меня уже просто заканчиваются буквы ))

Цитата

в новом Стандарте будут объявлены устравшими.

объявлены может и будут, но это не значит, что они будут их нельзя будет использовать и дальше.
Это всего лишь означает, что следующая версия Visual Studio будет вас об этом предупреждать.

Кстати, на почве этой темы даже "холи-вар" может случиться. Если это произойдёт, думаю модераторы позаботятся о том, чтобы перенести её в соответствующий раздел. Если же по существу. То тема себя исчерпала, ответы даны. Спасибо всем участникам дискуссии!

Цитата zzz7net @ 15.02.11, 08:26

С чего бы это?

Я прочитал это у Рихтера в Создание эффективных WIN32-приложений с учётом специфики 64-разрядной версии Windows в 6 ой Главе. Но объяснения так и не нашел

Добавлено 16.02.11, 16:08
Цитата:

Цитата

Многопоточная версия библиотеки С/С++, кроме того, "обёртывает" некоторые функции синхронизирующими примитивами. Ведь если бы два потока одновременно вызывали функцию malloc, куча могла бы быть повреждена. Поэтому в многопоточной версии библиотеки потоки не могут одновременно выделять память из кучи. Второй поток она заставляет ждать до тех пор, пока первый не выйдет из функции malloc, и лишь тогда второй поток получает доступ к malloc. (Подробнее о синхронизации потоков мы поговорим в главах 8, 9 и 10.)

zzz7net, с твоими доводами не согласны ни Комитет по стандартизации языка, тем более, что реально букв вдвое меньше, ни сопроводители унаследованного кода, ни пользователи специализированных платформ, типа той же OLE, которая языконезависима. Ну и три буквы ты сам себе выдумал. Поверь, в мире писатели под только одну платформу и зарабатывающие на этом составляют подавляющее меньшинство. К примеру, выходящие параллельно на нескольких платформах игры давно никого не удивляют. Как думаешь, сколько кода они специализируют под разные порты, а сколько универсального?
like-nix, конкретно с небезопасными к мультипоточному окружению функции RTL сама разбирается. И malloc()/free() тут не исключение. Сабжевые же wcstok() и strtok() небезопасны в пределах одного потока, и в этом большая разница. Как раз с многопоточносью они разберутся не хуже других функций.
Можно сколько угодно раз сколько угодно большими буквами как только можно ярко произвольной жирности болдом писать в документации, что wcstok() и strtok() не могут работать одновременно с более чем одной строкой, обязательно время от времени кто-нибудь будет жутко материться, вылезая из отладчика. Потому что не все считают обязательным читать документацию. Потому что некоторые считают это даже ниже своего достоинства, ибо они по определению лучше всех всё знают, и не надо их учить, как правильно и почему. Потому что человеческий фактор, в конце концов. Типичный пример - рекурсивный обход дерева каталогов с поиском имён файлов по маске. М-м? Насторожило бы, если б не эта тема, и я в ней не привёл этот пример с рекурсией? Особенно учитывая

Цитата zzz7net @ 16.02.11, 15:09

Но в большинстве случаев всё таки не требуется производнить разбор 2-х и более строк, ...

Привык к отсутствию проблем, забыл об ограничении, не полез в документацию, на автомате набыдлокодил. Вуаля.
Неспроста эти все _s(). Конкретно о том примере с потенциальным эксплойтом. Дело в переполнении. Простом целочисленном. Достаточно передать через сокет заголовок пакета с numElements немногим более 1Г, и на 32-битной машине умножение на 4 приводит в малому положительному объёму, который malloc() успешно найдёт. Затем передать через тот же сокет в том же пакете немногим более полученного малого объёма, и мы трём блок хипа следом за вернутым, а то и не один. Рвём соединение со своей стороны, пакет отвергается, блок освобождается, не дожидаясь размера в 1Г интов. Никто ничего не заметил, кроме юзера, у которого ютубный ролик просто не проигрался. Обидно, но не сильно. Вот если б он знал бы, что затёртый блок в хипе уже содержит код эксплойта, и плейером используется под некую структуру с указателем на функцию, который указывает уже далеко не на ту функцию, а на эксплоит, ему было бы обиднее куда сильнее. Ну да, ещё DEP есть. Вот только честно: у кого он стоит в положении OptOut? Да даже OptIn, если только браузер не IE.
Комбинация факторов, мягко говоря, маловероятна, не спорю. Однако ютуб очень посещаемый ресурс.

Сообщение отредактировано: Qraizer - 16.02.11, 17:28