With the Visual Studio 2005 C++ compiler, I get the following warning when my code uses the fopen() and such calls:
1>foo.cpp(5) : warning C4996: 'fopen' was declared deprecated
1> c:\program files\microsoft visual studio 8\vc\include\stdio.h(234) : see declaration of 'fopen'
1> Message: 'This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help for details.'
How do I prevent this?
It looks like Microsoft has deprecated lots of calls which use buffers to improve code security. However, the solutions they're providing aren't portable. Anyway, if you aren't interested in using the secure version of their calls (like fopen_s), you need to place a definition of _CRT_SECURE_NO_DEPRECATE before your included header files. For example:
#define _CRT_SECURE_NO_DEPRECATE
#include <stdio.h>
The preprocessor directive can also be added to your project settings to effect it on all the files under the project. To do this add _CRT_SECURE_NO_DEPRECATE to Project Properties -> Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions.
Well you could add a:
#pragma warning (disable : 4996)
before you use fopen, but have you considered using fopen_s as the warning suggests? It returns an error code allowing you to check the result of the function call.
The problem with just disabling deprecated function warnings is that Microsoft may remove the function in question in a later version of the CRT, breaking your code (as stated below in the comments, this won't happen in this instance with fopen because it's part of the C & C++ ISO standards).
This is just Microsoft being cheeky. "Deprecated" implies a language feature that may not be provided in future versions of the standard language / standard libraries, as decreed by the standards committee. It does not, or should not mean, "we, unilaterally, don't think you should use it", no matter how well-founded that advice is.
If you code is intended for a different OS (like Mac OS X, Linux) you may use following:
#ifdef _WIN32
#define _CRT_SECURE_NO_DEPRECATE
#endif
I'am using VisualStdio 2008.
In this case I often set Preprocessor Definitions
Menu \ Project \ [ProjectName] Properties... Alt+F7
If click this menu or press Alt + F7 in project window, you can see "Property Pages" window.
Then see menu on left of window.
Configuration Properties \ C/C++ \ Preprocessor
Then add _CRT_SECURE_NO_WARNINGS to \ Preprocessor Definitions.
Consider using a portability library like glib or the apache portable runtime. These usually provide safe, portable alternatives to calls like these. It's a good thing too, because these insecure calls are deprecated in most modern environments.
If you want it to be used on many platforms, you could as commented use defines like:
#if defined(_MSC_VER) || defined(WIN32) || defined(_WIN32) || defined(__WIN32__) \
|| defined(WIN64) || defined(_WIN64) || defined(__WIN64__)
errno_t err = fopen_s(&stream,name, "w");
#endif
#if defined(unix) || defined(__unix) || defined(__unix__) \
|| defined(linux) || defined(__linux) || defined(__linux__) \
|| defined(sun) || defined(__sun) \
|| defined(BSD) || defined(__OpenBSD__) || defined(__NetBSD__) \
|| defined(__FreeBSD__) || defined __DragonFly__ \
|| defined(sgi) || defined(__sgi) \
|| defined(__MACOSX__) || defined(__APPLE__) \
|| defined(__CYGWIN__)
stream = fopen(name, "w");
#endif
For those who are using Visual Studio 2017 version, it seems like the preprocessor definition required to run unsafe operations has changed. Use instead:
#define _CRT_SECURE_NO_WARNINGS
It will compile then.
Many of Microsoft's secure functions, including fopen_s(), are part of C11, so they should be portable now. You should realize that the secure functions differ in exception behaviors and sometimes in return values. Additionally you need to be aware that while these functions are standardized, it's an optional part of the standard (Annex K) that at least glibc (default on Linux) and FreeBSD's libc don't implement.
However, I fought this problem for a few years. I posted a larger set of conversion macros here., For your immediate problem, put the following code in an include file, and include it in your source code:
#pragma once
#if !defined(FCN_S_MACROS_H)
#define FCN_S_MACROS_H
#include <cstdio>
#include <string> // Need this for _stricmp
using namespace std;
// _MSC_VER = 1400 is MSVC 2005. _MSC_VER = 1600 (MSVC 2010) was the current
// value when I wrote (some of) these macros.
#if (defined(_MSC_VER) && (_MSC_VER >= 1400) )
inline extern
FILE* fcnSMacro_fopen_s(char *fname, char *mode)
{ FILE *fptr;
fopen_s(&fptr, fname, mode);
return fptr;
}
#define fopen(fname, mode) fcnSMacro_fopen_s((fname), (mode))
#else
#define fopen_s(fp, fmt, mode) *(fp)=fopen( (fmt), (mode))
#endif //_MSC_VER
#endif // FCN_S_MACROS_H
Of course this approach does not implement the expected exception behavior.
I also got the same problem. When I try to add the opencv library
#include <opencv\cv.h>
I got not a warning but an error.
error 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. c:\program files (x86)\opencv\build\include\opencv2\flann\logger.h
I also used the preprocessor directives as mentioned. But that didn't solve the problem.
I solved it by doing as follows:
Go to Properties -> C/C++ -> Precompiled Headers -> Choose Not Using Precompiled Headers in Precompiled Header.
Related
If I use the _byteswap_uint64() intrinsic of MSVC with the mostly MSVC compatible compiler clang-cl the code generates a call to the external library function _byteswap_uint64() which does the well known mask and shift orgy. Whith MSVC I simply get a x86 BSWAP instruction which is there since the 486 so there shouldn't be any processor optimization level relevant here. clang-cl understands a lot of command line options MSVC doesn't understand, even -march=native. So if I have -march=native the code is still a call to the mentioned function.
I use clang-cl 13 through the IDE (installed from the Visual Studio installer).
Is there a way to get proper code like with MSVC ?
I've got it. Simply use the clang specific intrinsics with conditional compilation:
#include <cstdint>
#include <intrin.h>
uint64_t swapThis( uint64_t value )
{
#if defined(__llvm__)
return __builtin_bswap64( value );
#elif defined(_MSC_VER)
return _byteswap_uint64( value );
#endif
}
clang_ isn't defined with clang-cl under Windows but only with clang++ under Windows, so I had to use _llvm.
So here is the preprocessed output of a struct:
typedef struct RPT_Item
{
wchar_t *fullPath;
RPT_ItemFlags_t itemFlags;
int isComposite;
const void *reserved;
} RPT_Item_t;
Visual Studio complains because wchar_t is not defined, its own cryptic way:
error C2016: C requires that a struct or union has at least one member
I looked at the project files and also at the particular C file where the error appears and I can confirm that "Treat wchar_t as built-in type is set to YES".
If I define the type using a typedef it compiles fine.
I used the preprocessor output so I can exclude that some nasty preprocessor #define trick play the main role.
This project contains many low-level hacks, for example the CRT is not linked (/NODEFAULTLIB).
Most of the code is not written by me, and I'm tasked to remove reference to wchar.h from a public header that uses wchar_t, because VS treats it as a built in type default. (This particular module is built only on Windows.)
I totally ran out of ideas. Is there a compiler option or a pragma that can interfere? Or could it be even a compiler bug?
Microsoft didn't explicitly document this until VS 2013, but the docs for /Zc:wchar_t says
The wchar_t type is not supported when you compile C code.
It seems that including nearly any header from the runtime or from the SDK will typedef wchar_t tounsigned short using the following sequence:
#ifndef _WCHAR_T_DEFINED
typedef unsigned short wchar_t;
#define _WCHAR_T_DEFINED
#endif
you might want to do something similar in your file that uses wchar_t.
Note that when compiling a C++ file, if /Zc:wchar_t is in effect then the compiler pre-defines _WCHAR_T_DEFINED. If /Zc:wchar_t- is in effect it doesn't - so the above snippet should work nicely with C++ as well (for MSVC anyway - I don't know how other compilers might deal with this if you're looking for something portable).
The _WCHAR_T_DEFINED macro is documented:
MSVC Predefined Macros
I need my application to be upgraded from visual studio 2005 IDE to visual studio 2012 .
The upgradation wizard converts the solution and project files successfully with 0 errors and few warnings.
But when i start building the application i get error message :
error C1189: #error : This file requires _WIN32_WINNT to be #defined at least to 0x0403. Value 0x0501 or higher is recommended. in atlcore.h !
I tried changing the version no to 0x0500 , 0x0501 , 0x0502 and also 0x0601 ( both through /D compiler option and manually changing in atlcore.h , WINVER is also changed. ) but no luck . the same error is being displayed.
Where do i go wrong ?
Visual C++ no longer supports targeting Windows 95, Windows 98, Windows ME, or Windows NT. If your WINVER or _WIN32_WINNT macros are assigned to one of these versions of Windows, you must modify the macros.
To modify the macros, in a header file, add the following lines.
#define WINVER 0x0500
#define _WIN32_WINNT 0x0500
EDIT:
WINVER determines the minimum platform SDK required to build your application, which in turn will determine at compile time which routines are found by the headers.
#define _WIN32_WINNT_NT4 0x0400
#define _WIN32_WINNT_WIN2K 0x0500
#define _WIN32_WINNT_WINXP 0x0501
#define _WIN32_WINNT_WS03 0x0502
#define _WIN32_WINNT_WIN6 0x0600
#define _WIN32_WINNT_VISTA 0x0600
#define _WIN32_WINNT_WS08 0x0600
#define _WIN32_WINNT_LONGHORN 0x0600
#define _WIN32_WINNT_WIN7 0x0601
Other Solution:
If you have installed a WIndows SDK on your PC (in /Microsoft SDKs/Windows), you can #include in stdafx.h (or in a header you include in all your C++ files). Including SDKDDKVer.h will target the highest Windows version available.
Hopefully It work!!!!!
For more info SEE HERE
Problem temporarily solved by commenting a check in atlcore.h :
if _WIN32_WINNT > 0x0501
//#error This file requires _WIN32_WINNT to be #defined at least to 0x0403. Value 0x0501 or higher is recommended.
endif
I know it isnt the right way to do [ editing a file shipped by the IDE ] but did since it may be due to Improper installation.
If anyone come across a permanent fix let me know .
you can add a pre-processor directive for the project under project settings, C/C++, Pre-processor definitions, appending WINVER=0x0501;
(you can also undefine definitions)
I'm wondering if you are using pre-compiled headers which is overwriting changes to stdafx.h, this is the way to make sure this is set
This preprocessor setting holds until code in the project files changes it, at which point if this doesn't fix the problem, then you must find how or where this is being set/unset/checked; but the solutions shouldn't involve any changes to the windows SDK files
I have a project that includes some performance sensitive native C++ headers making heavy use of templates. For this project we also wrap the headers and add some glue code to expose the functionality to c# and other .NET languages. We'll call this header "layout.h", and we'll assume it's a third party header that I can't change.
In a mixed mode C++/CLI assembly it is relatively easy to make a mistake and #include from a place in the code where #pragma unmanaged (or #pramga managed(push,off) ) . When that happens the templates generate IL, and I get extra managed/unmanaged transitions when running the code and performance goes down the drain.
My question is whether there is a way I can do a compile-time check just before the #include so that compilation fails if I am accidently #including from the wrong context.
// File1.cpp, compiled in a mixed mode C++/CLI assembly with /clr
ASSERT_UNMANAGED()
#include <layout.h>
My naive 1st attempt checked #ifdef _MANAGED, but that is always defined whether I'm in a #pragma unmanaged block of code or not.
The pragma directives must be inserted directly in the include file. In this way, everywhere you include the file an unmanaged section is declared.
Sorry that you have to modify your include file.
You may write ASSERT_MANAGED or ASSERT_UNMANAGED code that would use construct that is available ONLY while compiling managed or unmanaged. A ref class declaration is an example which is avaiable only when using managed.
This is somewhat a dirty solution, but it would work.
Here's a possible solution, making use of the fact that intrinsics are always compiled as native (unmanaged) code:
#include <intrin.h>
#define ASSERT_UNMANAGED() \
int TestFunc(void) { \
__pragma(warning(push)) \
__pragma(warning(error:4793)) \
auto aumt = [] () { return _bextr_u64(65537, 0, 8); }; \
__pragma(warning(pop)) \
return int(aumt()); }
#pragma unmanaged // Comment out this line and the assertion fails!
ASSERT_UNMANAGED()
#pragma managed
EDIT: Of course, if you just want warnings rather than compilation failure, you can remove the 3 __pragma(warning()) lines.
I'm using bison & flex (downloaded via cygwin) with vc++. When I compile the program I got an error:
...: fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory
The corresponding code in the flex-generated file is:
#ifndef YY_NO_UNISTD_H
/* Special case for "unistd.h", since it is non-ANSI. We include it way
* down here because we want the user's section 1 to have been scanned first.
* The user has a chance to override it with an option.
*/
/* %if-c-only */
#include <unistd.h>
/* %endif */
/* %if-c++-only */
/* %endif */
#endif
If I define YY_NO_UNISTD_H in the flex file(.l) this error will disappear, but I get several other errors:
...: error C2447: '{' : missing function header (old-style formal list?)
...: warning C4018: '<' : signed/unsigned mismatch
...: error C3861: 'isatty': identifier not found
How can I fix this problem?
All these errors occur in the flex-generated scanner.
I know it's because unistd.h doesn't exist in windows. Do I have to write my own unistd.h? If so how to write it in order to eliminate those errors?
isatty is used by the lexer to determine if the input stream is a terminal or a pipe/file. The lexer uses this information to change its caching behavior (the lexer reads large chunks of the input when it is not a terminal). If you know that your program will never be used in an interactive kind, you can add %option never-interactive to you lexer. When the program is run with user input, use %option interactive. When both uses are desired, you can either generate an interactive lexer, which gives a performance loss when used in batch mode, or provide your own isatty function.
Use %option nounistd in your .l file to remove the dependence on unistd.h.
just in case somebody's still this problem, Flex comes with unistd.h within its devel files. I found this here:
http://sourceforge.net/tracker/index.php?func=detail&aid=931222&group_id=23617&atid=379173
to put it short, just make sure your compiler can reach it. in my case it's just adding "C:\GnuWin32\include" to the additional inclusion directories
use win_flex.exe with option --wincompat and you dont need to hack your lex file
unistd.h is a UNIX header, so it's not present in VC++; your best bet is probably to compile it using g++ in Cygwin (or mingw/msys). You could also look at this question for other suggestions.
I'm using flex 2.5.4 that comes from the GnuWin32 project, which doesn't check for YY_NO_UNISTD_H.
In my version, Flex looks for unistd.h only when being compiled as C++, so you can save yourself all this trouble if your yylval doesn't use any C++ constructs.
I had to use the STL in yylval (using a pointer to make it a POD type), so in order to make flex compile in C++ I created this simple unistd.h:
#include <io.h>
That's all it takes (actually, I could copy the unistd.h file that comes with GnuWin32, like flyontheweb suggests).
P.S. To wrap things up: in Bison I put yylval's required STL header files in %code requires {} and added the current directory to the INCLUDE paths in my makefile.
I am too late but anyway I will share my findings to save someone still looking for answer.
In my case having an empty unistd.h file in the location where compiler looks for headers works for me.
Well this post is old but I face the same problem and here is something that should work.
WinFlexBison
I ran into this problem recently after upgrading to Angular 14.
npm install -g latest-version
resolved my issue.