Recently, we discovered that one of our external libraries (DLib) is suppressing warnings at a global level. Writing the following code gives us a warning:
[[deprecated]] int findDeprecated() { return 42; }
int test = findDeprecated();
Including a dlib header suppresses the warning:
#include <dlib/matrix.h>
[[deprecated]] int findDeprecated() { return 42; }
int test = findDeprecated();
Having to trigger all of these warnings in order to vet our external libraries is very cumbersome and not easy to integrate in our codebase.
Hence we would like to create a new test that conceptually looks like:
#include <dlib>
#include <boost>
static_assert(getWarningLevel(4996) == 4, "Deprecated Warning Was suppressed");
However, from searching around, we can't find a way to request the warning level as search engines always tell us how to enable the warning.
Does a way exist in order to retrieve the warning level?
Some restrictions to the answer:
We are only interested in Visual Studio 2017 (or above)
Extra points: Have a solution for clang-cl as well
You can save and restore your warning level(s) with:
#pragma warning(push) // Save current warning state
#include <offendingheaderfile.h>
#pragma warning(pop) // Restore saved warning state
Related
I am getting the following error when using the identifier DDRB:
identifier "DDRB" is undefined
But, when I click “go to definition”, the IDE does shows that it can find them. The code also compiles without any problem. I was using VScode first and setting intellisense to "tag parser" did work, but it also got rid of the error checking. So, I switched over to Visual Studio, but the issue remains. In both cases I included the AVR library.
I have googled quite a bit and found some solutions, but most were outdated or did not work. What can I do to resolve this issue?
"minimal reproducible example:"
#include <avr\io.h>
int main() {
DDRB |= (1 << DD3);
}
I can reproduce same issue in VS2017, and this one can be resolved by adding the #define __AVR_ATmega32U4__ above the #include <avr\io.h> like this:
#define __AVR_ATmega32U4__
#include <iostream>
#include <avr/io.h>
int main()
{
DDRB |= (1 << DD3);
}
After adding the macro definition, VS Intellisense option can recognize them well and the issue goes away. More details refer to Kissiel's reply. Thanks to him!
If you don't want to paste this definition into almost every file:
press f1
find C/C++; Edit configurations (UI)
paste your mcu name in Defines section e.g __AVR_ATmega32U4__
It worked for me in vs code.
MCVE:
#pragma warning(push,0)
#include <QWidget>
#pragma warning(pop)
#include <QVariant>
int main(int argc, char *argv[])
{
}
compiling with Visual Studio 2015 (choose "Qt Application" as project type if it matters) and /W4 i get 2xWarning C4100 (unreferenced formal parameter) for argc and argv which is what i expect and are actually interested in. But in addition i get 5xWarning C4251(class X needs to have dll-interface to be used by clients of struct Y) somewhere inside qvariant.h.
With different included files from Qt i can produce different warnings, so it's not just C4251. I was not able to reproduce it with standard library includes yet. The warnings disappear if i remove/comment the #pragma warning-lines or set the projects /W flag to a lower level. The level pushed seems to have no effect, so e.g. with /W0 and #pragma warning(push,4) i get no warnings.
What i would have expected is, that #pragma warning(push,0) disables all warnings inside <QWidget> and #pragma warning(pop) restores the initial state. Instead, Visual Studio seems to somehow detect that those files are from an external library (or is it something inside the Qt code?), but as soon as there is a push/pop pair the pushed warning-level is ignored and instead the initially set warning level via /W flag is used.
I came across this problem initially when using CMake and cotire, which automatically generates a header file to be used as precompiled header. So in my code i don't use #pragma warning (push/pop) which compiles fine without Qt-Warnings. But the generated file wraps the includes in a push/pop pair and thus generates about 200 Warnings in my project. I'm trying to understand why this happens in order to find a solution which requires me neither to wrap all my manual includes in push/pop nor to maintain a private modification to cotire.
I'm working on a C++ DDL, however I get the following issue in some places:
C4996 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
I did try #define _CRT_SECURE_NO_WARNINGS, but the issue remains.
This is the code:
sprintf(szDebugString, "%s: 0x%x (%s%s%i)", ptrName, (DWORD)funcPtr, interfaceName, interfaceVersion.c_str(), i);
You have to define _CRT_SECURE_NO_WARNINGS before #include <Windows.h>.
Alternatively, use the safe version:
sprintf_s(szDebugString, sizeof(szDebugString), "%s: 0x%x (%s%s%i)",
ptrName, (DWORD)funcPtr, interfaceName, interfaceVersion.c_str(), i);
To turn off the warning for an entire project in the Visual Studio IDE:
1- Open the Property Pages dialog for your project.
2- Select the Configuration Properties > C/C++ > Advanced page.
3- Edit the Disable Specific Warnings property to add 4996. Choose OK to apply your changes.
put this define into stdafx.h.
E.g.
#pragma once
#define _CRT_SECURE_NO_WARNINGS
#include "targetver.h"
#include <stdio.h>
#include <tchar.h>
In my point of view, on a Windows project, it is not a good idea to disable the warning; a better idea is to improve the code. Mute the warning not just keeps this potential code vulnerability unnoticed, but also blinds programmers when introducing other potential code vulnerabilities.
From the docs:
You can turn off the warning for a specific line of code by using the warning pragma, #pragma warning(suppress : 4996). You can also turn the warning off within a file by using the warning pragma, #pragma warning(disable : 4996).
https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996?f1url=https%3A%2F%2Fmsdn.microsoft.com%2Fquery%2Fdev15.query%3FappId%3DDev15IDEF1%26l%3DEN-US%26k%3Dk(C4996)%26rd%3Dtrue&view=vs-2017
My code works well without #openmp
but I got this error when I added #openmp compiler
1>c:\users\hdd amd ali\documents\v studio 10 projects\visual studio 2010\projects\escaledesvols2 - copy\escaledesvols2\djikstra.cpp(116): fatal error C1001: An internal error occurred in the compiler.
1> (compiler file 'f:\dd\vctools\compiler\utc\src\p2\wvm\mdmiscw.c', ligne 1098)
note:
i use many different libraries (like #boost)
#include <string>
#include <iostream>
#include <stdio.h>
#include <ctime>
#include <iomanip>
#include <sstream>
#include <msclr\marshal_cppstd.h> // for unmanaged piece of code
#include <vcclr.h>
I had this issue recently; I was compiling with visual studio 2015. I tried it with visual studio 2017 and I still got the internal compiler error. Then I tried it with visual studio 2013 and it told me that I can't have a "return" statement inside an openMP section. when I removed the return from VS 2013 and VS 2105 the compiler was able to successfully compile. So, it make sense to try it with VS 2013 and it will give you a better error description. You could also be having return statements inside openMP sections and that could be the reason for c1001 error.
In my case it was a return function from the OpenMP loop. Removing a "return" line solved the problem.
You should simply report it.
In terms of workarounds, it is likely related to memory/resource consumption. Usual tricks to lower consumption are
disable debug information
split up compilation units to smaller size (this might be key here: "I'm using many libraries" should not be an issue unless you're including all the headers in a single translation unit
try to reduce template instantiations
Alternatively
reduce system load (close other programs, such as your Stackoverflow browser that might tatke valuable resources :))
I'm facing an issue with c++ on vs2005 and also vs2008...
here's how you can reproduce the issue....
create a new (c++) project called 'test' (file|new|project)
select "Windows Forms Application"
and add the 'stdio.h' include and the code fragment below into the test.cpp source file.....
-------------------start of snippet--------------------
#include <stdio.h>
...
int main(array<System::String ^> ^args)
{
int i;
System::Threading::ThreadState state;
char str[20];
sprintf (str, "%s", "test string");
...
-------------------end of snippet--------------------
If you compile the code as above (you'll have to 'buildall' first), you'll get two warnings about 'i' and 'state' being unreferenced (nothing about sprintf being deprecated).
If you comment out "System::Threading :Thread state;", you'll get one warning about 'i' being unreferenced and another warning (C4996) for the 'deprecated' sprintf statement....
This issue also occurs for "System::Windows::Forms::MessageBoxIcon", "System::Base64FormattingOptions" (and perhap all 'enum class' types!)
Anyone know of the cause and workaround to the issue demonstrated here ( i have other files that demonstate this issue..). (I had started a thread on msdn, but then found this site! see link below)
Visual Studio 2005 has stopped warning about deprecated functions
This sounds like an issue you should take to Microsoft support.