pragma Support

#pragma Support

A pragmatic instruction (or directive) is a pre-processor directive recognized by the C++ compiler. These directives are quite practical because they enable you to manipulate and optimize the compilation of an application. Pre-processor directives are typically inserted before your source code.

Microsoft frequently uses #pragma directives to debug their code. Assuming you installed Visual Studio 2005 in the default C:\ directory, you can view and edit header files created by Microsoft staff. This will give you a bit of insight into how PREfast is used internally at Microsoft and what errors tend to come up during the test phase of a Microsoft product. These header files are contained in the following directory:

      C:\Program Files\Microsoft Visual Studio 8\VC\include\

In Team System, #pragma is used to programmatically reduce and filter unwanted noise. Let's take a look at how this is done: Warning 6001 indicates that you are trying to use an uninitialized variable somewhere in your application. The following example contains a code defect that will trigger the warning:

      1   #include <stdio.h>      2      3    int main ()      4    {      5      int myOutput;      6      return myOutput;      7    }

The problem occurs at line 6, where the code is trying to return a variable with an undeclared value. If you execute this code, Team System's C/C++ Code Analysis engine will return the following warning message:

      1   warning C6001: using uninitialized memory 'output': Lines: 5, 6

Let's say you are working on a test methodology and you would like to single out defects like these, which can cause corruption and instability in your application. Just add the following #pragma directive at the beginning of your application, and warning 6001 will be automatically converted into an error:

      #pragma warning (error: 6001)

The following code shows the result displayed in the Visual Studio Error List. Instead of the yellow yield symbol, you'll get a red X at the beginning of the line. The warning matches the error, but you also get an indication of where the error lies by row and column:

      1   using uninitialized memory testOutput.cpp 5, 6 46 

If you want to disable a warning outright, the disable warning specifier enables you to remove warnings from the Error List. To suppress the warning, you can use the following #pragma directive:

      #pragma warning (disable: 6001) 

Following is a list of some of the common commands you can use within the #pragma directive (for more information, be sure to take a look at the Pragma Directives article in the MSDN Library):

• once: The once specifier causes a warning to appear only once on the Error List. For example: #pragma warning (once:6011) will make the C6011 warning appear only once on the list even if there are multiple instances of the warning. This specifier is very useful to reduce the number of warning messages displayed in Visual Studio (thereby reducing unwanted noise).

• 1-4: This specifier sets the warning level between 1 and 4. This specifier is used in conjunction with push to set warning levels to a series of warning messages.

        #pragma warning(push,4)      #pragma warning(disable:6023)      #pragma warning(disable:6001)      #pragma warning(pop)

  Both warning 6023 and 6001 are assigned a warning level of 4.

• push: The push specifier supresses all warning states. This is useful if you want to disable a series of warnings, as shown in the following example:

        #pragma warning(push)      #pragma warning(disable:6031)      <Insert C++ Code here>      #pragma warning(pop)

• pop: The pop specifier restores all warning states.

Here is a cross-section of some of the common warnings you will encounter using Code Analysis for C/C++. You can view the complete list of warnings on the online MSDN Library:

• C6001 using uninitialized memory (var): This warning will occur after you've declared a variable's datatype and you forget to provide it with a default value, as shown here:

        int problemVar;      return problemVar;

  The obvious solution to this problem is to provide a value to the variable when you declare its datatype, as shown in the following example:

        int problemVar = 1000;

• C6014 leaking memory (pointer): This warning will occur if your function returns before you try to free it. Suppose you have a pointer called pLeak; the following line of code will cause a small memory leak, which may grow with time:

        if (pLeak){      ...      return;      free(pLeak);      }

  To correct this warning, always free your resources before you do a function return, as shown in the following example:

        if (pLeak){      ...      free(pLeak);      return;      }

• C6031 return value ignored: This warning code occurs if you forget to check for a return value, especially if you are performing a disk, file, or memory resource. The following line of code will cause you problems:

        fopen("leak.txt","w");

  To correct this problem, simply check for a return value in your code, as shown here:

        FILE *textFile;      if((textFile = fopen("noleak.txt","r"))==NULL)      return;