Как отключить _CRT_SECURE_NO_WARNINGS?

@Frstr · Регистрация: 11.03.2010

Студворк — интернет-сервис помощи студентам

Код - работа с файлом. Выдает ошибку warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
Прочел что как то надо отключить эту ошибку. Подскажите пожалуйста как это сделать в Visual Studio 2008

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
int f9()
 
{
FILE *file;
char* file_name = "file.txt";
char load_string[50] = "none";
 
file = fopen( file_name, "w" ); 
 
fputs( "string", file );
 
fclose( file );
 
file = fopen( file_name, "r" );
if( file != 0 )
{
fgets( load_string, 50 , file ); 
cout << "load_string = " << load_string << endl;
}
else
{
cout << "File not found !!!" << endl;
}
fclose(file);
}

@Optimus11 · 28.01.2019, 19:38

В этом коде, я просто добавил _CRT_SECURE_NO_WARNINGS в определение препроцессора.

nd2 · 28.01.2019, 20:04

Сообщение от Optimus11

В этом коде, я просто добавил _CRT_SECURE_NO_WARNINGS в определение препроцессора.

Сделай, как пишут в теме. Выше всех инклудов:

C++
1
#define _CRT_SECURE_NO_WARNINGS

@Optimus11 · 28.01.2019, 20:29

Это к сожалению не работает.

nd2 · 28.01.2019, 20:37

Сообщение от Optimus11

Это к сожалению не работает.

Покажи, как делал, как не работает. Скрин студии, с кодом, с выводом компилятора.

@Optimus11 · 28.01.2019, 21:03

Скриншот:

nd2 · 28.01.2019, 21:06

Сообщение от Optimus11

Скриншот:

В определениях препроцессора убери.

@Optimus11 · 28.01.2019, 21:41

Убрал, абсолютно тоже самое.

nd2 · 28.01.2019, 21:53

Сообщение от Optimus11

Убрал, абсолютно тоже самое.

Покажи скрин, и вывод компилятора. Именно вывод, а не список ошибок. Студия какая? В обозревателе решений что есть?

Добавлено через 3 минуты
Ты в курсе, что для Debug и Relese разные настройки?

@valen10 · 28.01.2019, 21:58

Сообщение от Optimus11

#include "pch.h"

Вот в этот файл пропишите #define _CRT_SECURE_NO_WARNINGS куда-нибудь в самое начало, сразу после #pragma once, из остальных мест этот дефайн уберите. Или, как вариант, можно отключить предварительно скомпилированный заголовок, тогда будут работать оба других способа (только что провел эксперимент).

@Optimus11 · 28.01.2019, 22:49

Изменил Debug на Release, в чем разница не знаю, но заработало.

@COKPOWEHEU · 29.01.2019, 10:33

Сообщение от eva2326

Хороший код не агрит компиляторы.

C
1
2
3
4
#include <stdio.h>
int main(){
  printf("Hello world\n");
}

Это не то что хороший, это самый обычный код. В нормальных компиляторах он собирается без проблем, в msvs приходится городить костыли.

Сообщение от eva2326

(безопасные версии с суффиксом _s завезли в стандарт ещё в с++11)

Какими компиляторыми эти опциональные функции поддерживаются?
Пожалуйста, не путайте терминологию. Функции с суффиксом _s ничуть не безопаснее обычных.
Вот тут еще один фанатик msvs пытался доказать пригодность _s функций. Разумеется, не преуспел.

Сообщение от eva2326

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

Что? Вы имеете в виду написать вокруг стандартных функций обертки для имитации нестандартных, что-то вроде такого что ли?

C
1
2
3
#ifndef __STDC_LIB_EXT1__
#define printf_s(...) printf(...)
#endif

Нет уж спасибо, обойдемся без подобного изврата, уж лучше заставить целевой компилятор принимать стандарт.

Сообщение от eva2326

А вот необходимости делать плохо, когда можно сделать хорошо - не существует.

Вот именно! Зачем писать компиляторо-зависимый код, когда можно писать кроссплатформенно?
Optimus11, попробуйте еще добавить

C
1
#pragma warning(disable:4996)

@Azazel-San · 29.01.2019, 11:33

Не по теме:

Сообщение от COKPOWEHEU

Вот тут еще один фанатик msvs пытался доказать пригодность _s функций. Разумеется, не преуспел.

Не возникало ли у вас чувства, будто это один и тот же человек?

@COKPOWEHEU · 29.01.2019, 12:27

Не по теме:

Azazel-San, вот только психоанализа фанатиков мне и не хватало! %-)

@eva2326 · 29.01.2019, 16:29

Сообщение от COKPOWEHEU

Это не то что хороший, это самый обычный код. В нормальных компиляторах он собирается без проблем, в msvs приходится городить костыли.

msvs - это не компилятор, а студия.
Студийный компилятор так же собрал этот код без каких либо проблем.
Так о чем это вы?

Сообщение от COKPOWEHEU

Вот тут еще один фанатик msvs пытался доказать пригодность _s функций. Разумеется, не преуспел.

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

Сообщение от COKPOWEHEU

Нет уж спасибо, обойдемся без подобного изврата

Вас же никто не заставляет так извращаться.

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

Сообщение от COKPOWEHEU

Зачем писать компиляторо-зависимый код

Вы и не обязаны.
Можете использовать любые стандартные функции, включая небезопасные.

Зачем следовать рекомендациям компилятора, вы хотели спросить?
Затем, что бы код был надёжным.

Сообщение от COKPOWEHEU

уж лучше заставить целевой компилятор принимать стандарт.

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

Если вы считаете, что вам не нужна падушка безопасности,
и вы предпочитаете ездить не пристёгиваясь ремнем,
то вы всегда можете отключить это предупреждение.

Для этого не нужно ослаблять защиту стандартной библиотеки.

1.
Некрасивый способ:
В самом начале предварительно скомпилированного заголовка:
#pragma warning(disable:4996)

2.
Корректный способ:
Правый клик по проекту -> свойства -> c/c++ -> все опции.
Ищем вкладку: Disable Specific Warnings
Указываем значение: 4996

Если нужно подавить несколько предупреждений - вписываем через точку-с-запятой.

И фсё!

Оставьте в покое _CRT_SECURE_NO_WARNINGS

И не имейте привычки трогать имена,
которые зарезервированы для нужд языка.

5.10 Identifiers
In addition, some identifiers are reserved for use by C++ implementations and shall not be used otherwise; no
diagnostic is required.
(3.1) — Each identifier that contains a double underscore __ or begins with an underscore followed by an
uppercase letter is reserved to the implementation for any use.
(3.2) — Each identifier that begins with an underscore is reserved to the implementation for use as a name in
the global namespace.

@COKPOWEHEU · 29.01.2019, 17:17

Сообщение от eva2326

msvs - это не компилятор, а студия.

Как называется их компилятор и как его называть чтобы окружающие поняли что речь именно о нем? На самом деле никогда особо не интересовался ни самой Студией, ни их компилятором. По слухам, оно неприлично тяжелое и любит выдавать ошибки на ровном месте (та же 4996)

Сообщение от eva2326

Студийный компилятор так же собрал этот код без каких либо проблем.
Так о чем это вы?

У меня этого компилятора нет, я не могу с ходу придумать и проверить пример, выдающий ошибку.

Сообщение от eva2326

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

А еще то, что кроме них это никому не нужно. Или вы знаете другие компиляторы, в которых это реализовано?
Задумайтесь, почему тот же gcc, который ЕМНИП лучше всех следит за стандартом, не спешит их реализовывать? Почему clang не спешит? Почему никто не спешит?
На самом деле эти функции еще опаснее стандартных, поскольку называются "безопасными", но не являются таковыми, то есть дают чувство ложной безопасности.

Сообщение от eva2326

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

Безопасны только математические функции, и то не всегда.
А вот обычные использовать не получается: msvs ругается и говорит "мы тут придумали новые функции, поэтому стандартные теперь запрещены". Для уменьшения совместимости придумали, что ли?

Сообщение от eva2326

Зачем следовать рекомендациям компилятора, вы хотели спросить?

Если рекомендации разумны (как большинство warning'ов) то да.
Но не тогда, когда рекомендации компилятора снижают качество кода, его переносимость и надежность.

Сообщение от eva2326

Предупреждение от компилятора - предупреждение, а не ошибка.

4996 это не предупреждение, а ошибка. Оно прерывает компиляцию, собственно весь топик об этом.

Сообщение от eva2326

Если вы считаете, что вам не нужна падушка безопасности,
и вы предпочитаете ездить не пристёгиваясь ремнем,

Не подменяйте понятия. Использовать псевдо-безопасные функции это все равно что привязывать себя к сиденью скотчем: от реальной опасности не защитит, зато при повседневном использовании активно мешает.

Сообщение от eva2326

1.
Некрасивый способ:
В самом начале предварительно скомпилированного заголовка:
#pragma warning(disable:4996)
2.
Корректный способ:
Правый клик по проекту -> свойства -> c/c++ -> все опции.
Ищем вкладку: Disable Specific Warnings
Указываем значение: 4996

Еще один вредный совет.
Потому что распространять исходные коды в виде "проекта" под какую-то конкретную IDE - плохая идея. Хотя бы потому что не все пользуются той же IDE, что у вас, и тем более той же версией IDE. Поэтому лучший способ распространения программ - набор исходных кодов + configure + make или что-то подобное вроде cmake.
А поскольку отдельные файлы исходного кода могут быть скопированы в другой проект, полагаться на настройки компилятора нельзя и там. Так что самый правильный способ - вынести все платформо- или компиляторо-зависимое в слой совместимости. Но если код построен на стандартных библиотечных функциях и нормальные компиляторы его собирают без ошибок, можно ограничиться костылем для компенсации багов в остальных. Например, так:

C
1
2
3
4
5
6
#if defined(_WIN32) || defined(__WIN32__) || defined(WIN32)
  //костыль для совместимости с msvs
  #define _CRT_SECURE_NO_WARNINGS
  #pragma warning(disable:4996)
...
#endif

Сообщение от eva2326

И не имейте привычки трогать имена,
которые зарезервированы для нужд языка.

В данном случае макроконстанта использована по прямому назначению: отключение назойливой рекомендации псевдо-безопасных функций. Она специфична для msvs и предназначена именно для этого.

@eva2326 · 29.01.2019, 19:04

Сообщение от COKPOWEHEU

По слухам

Дальше не читала))

Сообщение от COKPOWEHEU

Почему никто не спешит?

Вопрос из серии: "почему язык си такой раздолбайный, и так легко поощряет выстрел в ногу?"

Студия спешит)
Стандарт одобрил.
Самое главное - у них дизайн использования более безопасный.

Сообщение от COKPOWEHEU

На самом деле эти функции еще опаснее стандартных, поскольку называются "безопасными", но не являются таковыми, то есть дают чувство ложной безопасности.

Почему это они не являются таковыми?
Учитывая, что используя их сложнее допустить ошибку.

Сообщение от COKPOWEHEU

4996 это не предупреждение, а ошибка.

Что за манера авторитетно заявлять то, в чем вы ни бум-бум?

Может быть стоило хотя бы с документацией сначала ознакомиться?
https://docs.microsoft.com/ru-... ew=vs-2017

Сообщение от COKPOWEHEU

Оно прерывает компиляцию, собственно весь топик об этом.

Вы об этом?

Сообщение от Frstr

Выдает ошибку warning C4996:

Нет, оно не прерывает компиляцию))
Видите ли, есть разница между warning и error

Сообщение от COKPOWEHEU

Еще один вредный совет.
Потому что распространять исходные коды в виде "проекта" под какую-то конкретную IDE - плохая идея. Хотя бы потому что не все пользуются той же IDE, что у вас, и тем более той же версией IDE. Поэтому лучший способ распространения программ - набор исходных кодов + configure + make или что-то подобное вроде cmake.

Это вообще никак не коррелирует.
И кстати, если вы вдруг не в курсе,
ваши make/cmake вполне себе определяют формат проекта.

Ну сделайте на make/cmake.
Это не принципиально.

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

Сообщение от COKPOWEHEU

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

Студия тоже без ошибок собирает.

Никто ж не виноват, что вы ошибки и предупреждения не различаете.

Сообщение от COKPOWEHEU

Она специфична для

Разработчиков, а не для пользователей.
Согласно правилам языка с++, вы со своим костылем завезли в проект UB

Такое может прокатить где нибудь в boost.
Тамошний склад костылей и UB жестко контролируется многочисленными тестами
на каждой заявленной кофеварке во всех возможных конфигурациях.

Но не в исходном коде бизнес-приложения.

В одном я с вами согласна: представленный вами код - это костыль.
В остальном, я бы не стала полагаться на мнение человека,
который не знает специфику CL (компилятор vc),
и даже не различает где ошибка, а где предупреждение.

@COKPOWEHEU · 30.01.2019, 11:06

Сообщение от eva2326

Вопрос из серии: "почему язык си такой раздолбайный, и так легко поощряет выстрел в ногу?"

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

Сообщение от eva2326

Почему это они не являются таковыми?

Потому что сама структура этих функций построена с расчетом на аккуратность разработчика, и подпорками (постоянными запросами на размер буфера) это не исправить. Если уж хочется действительно безопасных функций - используйте С++: вместо printf/scanf -> std::cout/std::cin, вместо strcpy -> std::string и т.д.

Сообщение от eva2326

Видите ли, есть разница между warning и error

Я-то ее вижу. Error - ошибка несоответсвтвия кода языку (его вообще невозможно скомпилировать), warning - скорее всего, логическая ошибка. То есть код скомпилируется, но работать будет неправильно. Иногда - действительно просто предупреждение оптимизации: неиспользуемые переменные, неудачное форматирование и т.п. Изредка бывают и ложные срабатывания.

Сообщение от eva2326

Никто ж не виноват, что вы ошибки и предупреждения не различаете.

Кто ж виноват что вы их путаете.

Сообщение от eva2326

Согласно правилам языка с++, вы со своим костылем завезли в проект UB

Если бы речь шла о соответствии стандарту языка - да. Но в данном случае идет обход багов одного конкретного компилятора, так что поведение определяется именно компилятором, а не стандартом. Кстати, может знаете какой макроконстантой представляется компилятор msvs чтобы костылить именно его, а не всю win32 ветку?

Сообщение от eva2326

В остальном, я бы не стала полагаться на мнение человека,
который не знает специфику CL (компилятор vc),

Майкрософт наше все, кто не знает всех багов и особенностей тамошнего компилятора, тот не знает Си!
... ох уж эти фанатики

@eva2326 · 04.02.2019, 15:20

Сообщение от COKPOWEHEU

Ну, раз на вопрос о небезопасности Си ответить легко, почему же вы затрудняетесь с Ответом на такой же по сложности вопрос о псевдо-безопасных функциях?

Я уже ответила:
по той же самой причине, по которой сишка - самый раздолбайный язык.

Что не понятного?

Может вы не знаете, почему сишка - раздолбайный язык?

Сообщение от COKPOWEHEU

Потому что сама структура этих функций построена с расчетом на аккуратность разработчика, и подпорками (постоянными запросами на размер буфера) это не исправить.

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

Сообщение от COKPOWEHEU

Я-то ее вижу. Error - ошибка несоответсвтвия кода языку (его вообще невозможно скомпилировать), warning - скорее всего, логическая ошибка. То есть код скомпилируется, но работать будет неправильно. Иногда - действительно просто предупреждение оптимизации: неиспользуемые переменные, неудачное форматирование и т.п. Изредка бывают и ложные срабатывания.

Вы там выше писали про ошибку компиляции

Сообщение от COKPOWEHEU

Оно прерывает компиляцию, собственно весь топик об этом.

Что же вы теперь начинаете юлить и соскакивать?

Мальчики, которые не умеют признавать свои ошибки,
и начинают юлить ака вороватые лесички - хуже девочек.

Сообщение от COKPOWEHEU

ох уж эти фанатики

Ох уж эти балбесы.
Сами ничерта не знают. Зато язычком мелят

@COKPOWEHEU · 05.02.2019, 10:05

Сообщение от eva2326

Я уже ответила:

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

Сообщение от eva2326

В более безопасных версиях сложнее накосячить

В более безопасных (std::cin / std::cout) - да, но мы же не про них говорим, а про функции с иллюзией безопасности. А они реальной безопасности не добавляют (или сумеете привести пример?), зато раздувают код и увеличивают количество передаваемых параметров, что увеличивает риск в них запутаться.

Сообщение от eva2326

Что же вы теперь начинаете юлить и соскакивать?

Ошибка 4996 достаточно серьезна (по мнению Microsoft, конечно же) чтобы прервать сборку программы. Это не предупреждение о том, что код, возможно, будет делать не то, что ожидалось (implementation defined behaviour) и которое можно, а иногда и нужно, проигнорировать.

Сообщение от eva2326

Ох уж эти балбесы.
Сами ничерта не знают. Зато язычком мелят

Вообще безобразие! Еще и смеют в стандарт носом тыкать, мол "опциональные функции, полагаться на их наличие нельзя", и аргументы приводить. Нет бы дружно уверовать в msvs, они-то точно скажут как написать красивый код, который потом будет легко поддерживать и портировать на другие платформы.
(нет! Как раз с этим у них самих все плохо)

@eva2326 · 08.02.2019, 18:16

Сообщение от COKPOWEHEU

Си разрешает стрелять в ногу по многим причинам. В частности потому что

Он раздолбай)

Сообщение от COKPOWEHEU

почему никто не спешит реализовывать псевдо-безопасные функции?

Потому что сишники - раздолбаи.

POSIX - стандарт раздолбаев.

А во главу сишного угла - идея о том, что на грабли можно тупо забивать.
По принципу: "итак сойдёт!"

Сообщение от COKPOWEHEU

они реальной безопасности не добавляют (или сумеете привести пример?)

Гуглите "уязвимости. переполнение буфера"

Сообщение от COKPOWEHEU

Ошибка 4996 достаточно серьезна (по мнению Microsoft, конечно же) чтобы прервать сборку программы. Это не предупреждение о том, что код, возможно, будет делать не то, что ожидалось (implementation defined behaviour) и которое можно, а иногда и нужно, проигнорировать.

Майкрософт здесь не причем.
Это только по вашему тупорылому мнению.

Вас ещё раз в документацию ткнуть?

Сообщение от eva2326

https://docs.microsoft.com/ru-ru/cpp...6?view=vs-2017

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

Прежде чем нести всякий бред.

Сообщение от COKPOWEHEU

Еще и смеют в стандарт носом тыкать, мол "опциональные функции, полагаться на их наличие нельзя"

Вас никто не заставляет полагаться на опциональные функции.

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

Ещё речь шла о том, что если уж приспичило ~~ездить не пристегиваясь ремешком~~ давить ворнинг,
то делать это нужно грамотно.
А не пихать в код UB.

Сообщение от COKPOWEHEU

Нет бы дружно уверовать в msvs

Как вариант, можете разбежаться со всей силы, и головой об стенку.

Новые блоги и статьи Все статьи Все блоги /
Доктрина интенционального знания - Доктрина для портала "Срез". Hrethgir 25.07.2026 Может найдётся кто захочет оценить доктрину. . . Написания правил участия для меня роскошь, требующая лимита времени, поэтому все сообщения не прошедшие модерацию будут видны только участникам портала,. . .	сукцессия 44. Решил подать на припринт в межународные сервисы препринтов. Но нужно одобрение от ученых anaschu 25.07.2026 Английский вариант. Пока кто то не одобрит мою личность, мне не получиться это опубликовать на препринте. Но заявку на публикацию статьи я сегодня подам.	сукцессия 43. Вторая научная статья за месяц- прайминг и гатгил anaschu 25.07.2026 две стороны одной монеты	Более приземисто - Эстафету хвоста в .cdl (деревья эстафеты в сад). Hrethgir 25.07.2026 В будущем, после написания блока инверсии обхода дерева (эстафеты хвоста), я планирую вернуться к нашему прошлому разговору о том, обладают ли знания целеполаганием. Тогда я пришел к выводу, что. . .
Вот представьте что вам дали бессмертие. kumehtar 25.07.2026 Вот представьте что вам дали бессмертие, ничего более не меняя. Вообще ничего, только бессмертие в нынешнем виде. Рады были бы? Что бы вы тут делали всё это время? Никакой пенсии. Никакого нового. . .	сукцессия 41 anaschu 24.07.2026 Численная верификация бифуркации в агентной модели лесной сукцессии: от одного параметра к ансамблю Автор: пользователь @Shumilov_AS \| Раздел: Прикладная математика / Численные методы Кратко. . .	сукцессия 40. Ансамблевая кластерная параметризаци, часть 1. anaschu 24.07.2026 Пр# Сопровождение научной статьи ИИ-ассистентом: подготовка публикации и калибровка агентно-ориентированной модели сукцессии микоризных систем Полевые заметки о двухнедельной совместной работе. . .	Теория всего 12. ВГК на планете в стратегической игре "терра" anaschu 22.07.2026 ### Главные семантические изменения и дешифровка новой физики 1. `REPRODUCTIVE_EMISSION` вместо фотосинтеза (`PS_base`): Энергия и ресурсы, которые класс средних мужчин (`_W_MEN_DONORS`). . .

@Optimus11 -41 / 49 / 5 Регистрация: 10.01.2017 Сообщений: 1,915
	28.01.2019, 19:38
	В этом коде, я просто добавил _CRT_SECURE_NO_WARNINGS в определение препроцессора. 0

@Optimus11 -41 / 49 / 5 Регистрация: 10.01.2017 Сообщений: 1,915
	28.01.2019, 20:29
	Это к сожалению не работает. 0

@Optimus11 -41 / 49 / 5 Регистрация: 10.01.2017 Сообщений: 1,915
	28.01.2019, 21:03
	Скриншот: 0

@Optimus11 -41 / 49 / 5 Регистрация: 10.01.2017 Сообщений: 1,915
	28.01.2019, 21:41
	Убрал, абсолютно тоже самое. 0

@Optimus11 -41 / 49 / 5 Регистрация: 10.01.2017 Сообщений: 1,915
	28.01.2019, 22:49
	Изменил Debug на Release, в чем разница не знаю, но заработало. 0

@COKPOWEHEU
	29.01.2019, 12:27
	Не по теме: Azazel-San, вот только психоанализа фанатиков мне и не хватало! %-) 0