VC++ Compiler: How to determine the current warning level or overrides?

Question

I've got a project where I've just discovered that warning C4244 (possible loss of data) is being suppressed. I strongly suspect that some crummy MS header is suppressing this warning and leaving it suppressed for all translation units that include said header, but I've not determined which of their myriad headers may be at fault.

So, like any other programming problem, I'd like to start by doing a binary search, printing out the current warning level and if possible any suppressed warnings in my main Pre Compiled Header.

Does anyone know what compiler directive I might use, or what approach I might be able to take that would give me that information?

I cannot tell you how obnoxious it is to find that my carefully constructed type declarations in my headers are failing to give a compiler warning when a caller violates the contract and tries to send me an integer instead of a signed byte (which has led to the current bug I'm trying to solve).

Thoughts?

NOTES:

Searches on #pragma through my entire solution come up with only balanced declarations of #pragma warning(disable:xxxx) followed by #pragma warning(default:xxxx). And none of those reference 4244.

Searches on 4244 throughout the entire solution return no matches (I never override that warning, nor do any of my included libraries, sub-projects, etc.).

Searches on 4244 throughout the entire MS include paths return a few references, that appear to be balanced, or almost so, depending on the #define symbols that were set before calling them. Hence my suspicion that MS is at fault (combined with prior history of MS doing sloppy work in their headers).

Answer 1

Can you just do a search through all the header files for "C4244" or do you only have access to pre-compiled header files?

Answer 2

You can start with using the /P compiler command line option. It outputs to a file the output of the preprocessor. this way you can actually make sure that its really a header that adds the warning disable and try to gather some hints as to which header it might be.

Answer 3

Another option is to add this

#pragma warning (defualt)

at the top of the file right after the #includes This resets the warning to the defualt, discarding any ignore which might have been called.

On a different note, I find it highly unlikely that an Microsoft header would disable a warning.

Answer 4

After further investigation:

/P takes too long (I never witnessed it getting beyond a few files over the course of nearly an hour, so I canceled that build)

I was never able to find a clear-cut way to print out what the current warning level was, or any overrides that were in effect at a given point in compilation. So the question I asked is not really answered, unless the /P argument actually is useful to you (as I mentioned, it was impractical for my purposes).

What I was able to do was to construct some inline calls in the various headers that should generate the requisite warning if the warning level included that warning as active, to verify if that warning was active or not:

inline int test(char value) { return ++value; }

include "something"

inline int test1(int value) { return test(value); } // should generate C4244 - possible loss of data if the previous #include didn't mess up the warning level or override warning 4244.

And so on...

In the end, what I discovered was that 4244 in particular has some odd rules associated with it, and that it is effectively "disabled" in all but /W4 (warning level 4) - the highest warning level. Since that warning level is very, very touchy and complains about lots of things that are well beyond our scope of doing anything about them, I didn't want to enable /W4.

What I did instead was to put the following in our stdafx.h PCH:

pragma warning(error:4244) // this fully enables warnings for possible data loss due to implicit type conversion in all circumstances regardless of the active warning level

That worked.

So, MS did not leave unbalanced warning overrides in any of their files that affected us. It was just that 4244 is very forgiving except at the highest warning level, where it becomes truly useful to us, anyway.

Thanks for your help!