Разница между strcpy_s и strcpy?

Добрый день!
Писал программу с использованием оператора strcpy.
Компилятор выдал такое вот предупреждение:
error C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead.
Чем отличается strcpy_s от strcpy?

0

это более "безопасный" аналог этих же функций, если не изменяет память они более потоко безопасны

Добавлено через 4 минуты
вот на msdn смысл _s функций
тык

0

Сообщение от Fatmarmelad Чем отличается strcpy_s от strcpy?

Функции с '_s' на конце и некоторые другие - это более безопасная альтернатива
некоторым функциям стандартной библиотеки. "Безопасный" в данном контексте - это:

* более строгая проверка аргументов;

* контроль выхода за пределы буфера (как правило, за счет дополнительного параметра);

* обеспечение завершающего нуля в некоторых случаях (там, где стандартные функции
такой гарантии не обеспечивают);

* строго определенная реакция на ошибку (как правило, приводит к срабатыванию
invalid_parameter_handler; поведение стандартных функций в аналогичных ситуациях,
как правило, не определено - UB);

* и т.д.

Более подробнее - здесь:

Security Features in the CRT
https://msdn.microsoft.com/en-... 0s5kh.aspx

0

Fatmarmelad, добавлю, что ходят слухи, что MS не имели право по умолчанию не компилировать функции определённые в стандартной библиотеки

0

Сообщение от rikimaru2013 что MS не имели право по умолчанию не компилировать функции

"Не имели права" - это звучит как-то слишком, как будто нарушили чьи-то
патентные требования или условия соглашения на много миллионов долларов...
Этак можно любой статический анализатор кода загнобить, что он не дает
проект нормально скомпилировать. Почему-то по поводу Secure CRT, SDL, SAL и т.п.
часто упреки в сторону MS слышу, как будто они кого-то насильно заставляют
этими возможностями пользоватся.

0

Сообщение от Убежденный как будто они кого-то насильно заставляют этими возможностями пользоватся.

И я о чём. Добавили фичу? Добавьте как галочку или еще как - но по умолчанию их фича работает, и её нужно отключать. Зачем лишнии действия)

0

Разве не логичнее, чтобы все новые фичи были по умолчанию включены?
Я бы, например, не хотел каждый раз при создании проекта явно включать
поддержку C++11/14.

0

Убежденный, а разве удобно открывая чужой проект/код у себя в VS приходится фиксить ошибки компиляции *_s

0

rikimaru2013, на счет этого согласен. При апгрейде проектов с предыдущих
версий Visual C++ стоило бы все новые опции оставлять выключенными, это разумно.
Но выдавать какой-нибудь варнинг во время апгрейда, что, мол, теперь доступна
такая-то опция, почитать можно здесь и т.п.

0

На всякий случай. strcpy_s и прочие аналоги являются микрософтовским расширением. Коды с их использованием будут непереносимыми.

GNU'шники пошли немного по другому пути. Они наваяли целую пачку специальных builtin'ов, а в системных хидерах стандартные интерфейсы определяют через эти builtin'ы. Таким образом и контроль появляется, и пользовательский исходник остаётся переносимым

https://gcc.gnu.org/onlinedocs... e-Checking

2

Убежденный, я к этому и клонил если перечитать мои посты)

0

Сообщение от Evg На всякий случай. strcpy_s и прочие аналоги являются микрософтовским расширением.

Сейчас уже это не совсем так. strcpy_s и некоторые другие похожие функции включены в стандарт С11.
Вот ссылка на TR 24731-1, который теперь часть стандарта С11.

2

Сообщение от Убежденный Разве не логичнее, чтобы все новые фичи были по умолчанию включены?

Логично в том случае, если они не ломают совместимость и соответствуют стандарту.
strcpy (в отличие, напримет от gets, которую убрали в c11) соответсвует всем стандартам C и С++.
Вывод ошибки при ее использовании говорит только об одном - отношении MS к стандартам.

1

Сообщение от gng Логично в том случае, если они не ломают совместимость и соответствуют стандарту.

Ну в таком случае поддержка по дефолту C++11 и выше в новых компиляторах не логична,
потому что ломает совместимость со старым кодом C++98/03. Давайте опять катить бочки на MS,
что они снова положили болт на совместимость и всех кинули.

Вывод ошибки при ее использовании говорит только об одном - отношении MS к стандартам.

Я смотрю на это иначе. Данная "принудиловка" в стиле MS - это попытка сразу отучать
начинающих программистов использовать древние окаменелости strcpy, strcat, sprintf и т.п.,
где очень легко нарваться на выход за пределы буфера или получить неопределенное
поведение программы. В этом случае есть хоть какая-то вероятность, что программист
обратит на это внимание и хотя бы поинтересуется на MSDN, почему это вдруг функции
стали небезопасными и код перестал компилироваться, и уже потом сделает для себя
выводы и выберет какой-то свой подход, а не будет сразу тупо задавливать варнинг
каким-нибудь _CRT_SECURE_NO_WARNINGS. Некоторый код лучше и правда никогда не
компилировать и не выпускать в продакшн.

Я бы вообще для новых проектов включал все доступные опции безопасности на максимум,
вместе с /Wall (treat warnings as errors), статическим анализом кода и всем остальным.
Все равно люди опытные в несколько кликов смогут перенастроить все под себя, а
начинающим будет полезно сразу включать все возможные проверки кода, хотя бы в
течение определенного времени.

0

Сообщение от DrOffset который теперь часть стандарта С11.

При вызове конструктора ошибка: L "Buffer is too small" & & 0

Сообщение от Croessmah Конечно, там написано, что реализация оставляет за собой право решить предоставлять эти функции или нет. В случае, если данные функции предоставляются, макрос _ _STDC_WANT_LIB_EXT1_ _ ставится в 1, если нет, то в 0.

Указать на пункт стандарта не могу,
т.к. под рукой нет C11, а качать с
моим текущим интернетом - тоже не вариант.

0

Croessmah, Однако даже так противоречий со сказанным мной нет. Я сказал, что функции включены в стандарт - ну так они включены, какие вопросы. Я сделал оговорку, что теперь эти функции нельзя считать исключительно Microsoft-specific даже с учетом того, что их может не быть в какой-то конкретной реализации.

0

Сообщение от DrOffset Однако даже так противоречий со сказанным мной нет.

Я уточнил, что их реализация не обязательна.

0

Сообщение от Croessmah Указать на пункт стандарта не могу

Сообщение от Croessmah Я уточнил, что их реализация не обязательна

Там по ссылке на TR про это тоже написано

0

Сообщение от rikimaru2013 а разве удобно открывая чужой проект/код у себя в VS приходится фиксить ошибки компиляции *_s

удобнее, чем игнорировать факт морального старения.

вы обновляете проект.
вы модернизируете проект так,
что бы он соответствовал веяниям нового времени.

зачем вы вообще это делаете, если хотите,
что б все оставалось по старому?

0

Сообщение от Убежденный Ну в таком случае поддержка по дефолту C++11 и выше в новых компиляторах не логична, потому что ломает совместимость со старым кодом C++98/03.

Поддержка по дефолту C++11 и выше оставит код с strcpy без предупреждений, даже с -Wextra (во всяком случае, и gcc, и clang поступают так), поскольку функция соответствует стандарту и при правильном использовании код не будет "дырявым".
Если подобным образом "приучать" новичков к "правильному" стилю, так лучше сразу рекомендовать писать код на Яве или на Решётке. Использование указателей само по себе потенциально несет больше угроз для безопасности, чем какая-то strcpy.
Причиной для МС отучать от подобных функций мне видится только желание "подсадить" на свои аналоги.

Добавлено через 12 минут
PS. И, все же, да.
И стандартизаторы, и разрабы компиляторов обратную совместимость ставят одной из основных целей и отходят от этого принципа разве что в исключительных случаях, напр. как с gets, которая явно открывает путь "дырам".

0