Quantcast
Channel: Code Analysis Team Blog
Viewing all 35 articles
Browse latest View live

FxCop 1.36 Beta Released!

$
0
0

I'm pleased to announce that we've released a beta of the next version of FxCop. This release has a number of changes since FxCop 1.35, including, but not limited to, the following:

  • 200+ bug fixes that reduce noise, missing analysis and rule crashes
  • Support for analyzing anonymous methods and lambda expressions
  • New option for skipping analysis over tool generated code
    • Turn this on in the UI via Project -> Options -> Spelling & Analysis -> Suppress analysis results against generated code
    • Turn this on in the command-line via /ignoregeneratedcode switch.
  • Better support for C++/CLI and the Compact Framework
  • Language 'friendly' API names in the UI and resolutions (ie Visual Basic syntax if running over a Visual Basic binary)
  • New globalization, design and usage rules
  • Performance improvements that cut analysis by 2x and use half as much memory
  • Documentation that is now available on MSDN

There are also some other underlying changes that I will talk about in some future posts.

Download it, and tell us what you think. If you have any feedback, bug reports or any questions, feel free to head over to the Code Analysis forum and ask away.


Code Metrics Customization

$
0
0

A number of people have asked:

Is there a way to customize the existing code metrics or add additional ones?

The simple answer at this time is No.  There are no extension points or customizations available at this time for code metrics.  This feature was added late in the cycle for VS 2008 and we were out of time to design and add the required hooks. We will use this release to gather feedback about the sorts of extensions you want. 

To that end please feel free to respond to this post with information about any customizations or additional metrics that would be of interest to you. This will help us a lot in our future planning.

Code Metrics as Check-in Policy

$
0
0

This is the first in a series of posts around questions I am getting asked related to code metrics.

One question that is coming up is:

Can a check-in policy be defined based on code metrics in TFS?

Well, code metrics itself does not have a check-in policy but fortunately the Maintainability Index, Class Coupling, Depth of Inheritance and Complexity metrics are all available as rules in Code Analysis in Visual Studio.  This means you can use code analysis check-in policy enabled with those rules.  The rules are grouped under the "Maintainability Rules" Category and are configured as follows:
 

MetricCorresponding RuleThreshold
Depth of InheritanceCA1501 AvoidExcessiveInheritanceWarning at above 5 levels deep
ComplexityCA1502 AvoidExcessiveComplexityWarning at above 25

Maintainability Index

CA1505 AvoidUnmaintainableCodeWarning at below 20
Class CouplingCA1506 AvoidExcessiveClassCoupling

Warning at above 80 for class and above 30 for a method

In the policy editor this would look like the following:

Code Metrics as a check-in policy

This allows you to enforce that code meets these thresholds before check-in.  In future we are looking in to allowing the threshold values to be changed.

Maintainability Index Range and Meaning

$
0
0

Another question:

The maintainability index has been re-set to lie between 0 and 100.  How and why was this done?

The metric originally was calculated as follows: Maintainability Index = 171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code)

This meant that it ranged from 171 to an unbounded negative number.  We noticed that as code tended toward 0 it was clearly hard to maintain code and the difference between code at 0 and some negative value was not useful.   I'll post some tech ed sample code showing very low maintainability or you can try on your own code to verify.  As a result of the decreasing usefulness of the negative numbers and a desire to keep the metric as clear as possible we decided to treat all 0 or less indexes as 0 and then re-base the 171 or less range to be from 0 to 100. Thus, the formula we use is:

Maintainability Index = MAX(0,(171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code))*100 / 171)

On top of that we decided to be conservative with the thresholds.  The desire was that if the index showed red then we would be saying with a high degree of confidence that there was an issue with the code.  This gave us the following thresholds (as mentioned in this blog previously):

For the thresholds we decided to break down this 0-100 range 80-20 so that we kept the noise level low and only flagged code that was really suspicious. We have:

  • 0-9 = Red
  • 10-19 = Yellow
  • 20-100 = Green

 

Positioning Code Metrics to Management

$
0
0

Another question that is coming up is:

How can (or should) code metrics be presented to management ?

My view is that in all cases the metrics are something that can help make decisions around focus and prioritization. Management should be made aware of the metrics and what they mean to allow them to decide where to focus resources. If management is more levels away from the code then the Maintainability index can serve as a good, simple, metric.

Sometimes you may ship code that has low maintainability or very high complexity etc. and management would make this decision based on risk, time and resources and perhaps other factors. Metrics helps them make that decision with quantitative data.

Some possible options:

  1. One option is to present the metrics in terms of risk and mitigation. For example:

    1. Risk: low maintainability in some module
    2. Mitigation: the module is reviewed.
    3. Risk: High cyclomatic complexity
    4. Mitigation: the module has a high number of test cases.
  2. Another option is to evaluate the metrics on legacy code. This could be to select some code that is known to have lots of issues and then run the metrics on the code to see if metrics would report any issues with the code. This could be a good way to show value to management in the metrics themselves and make them case for them as a future preventative measure.
  3. Yet another option is to present a trend over time. Unfortunately the tool doesn't currently make this very easy but at each milestone of the project you can record the maintainability and other metrics for the modules. This could then be compared across time and used in future planning or to guide management in allocating time and resources to particular parts of the project that are trending badly.

I'd be very interested in hearing other approaches people have taken in presenting metrics or code analysis in general to management.

Try the Code Analysis Rule Sets Feature in the November "Rosario" November 2007 CTP

$
0
0

We have a great new feature that we are previewing in Microsoft® Visual Studio® Team System code name “Rosario” November 2007 CTP.  This feature allows you to select pre-defined sets of rules to configure code analysis as well as define your own.  To access this feature right click on a project and choose "Properties" then click on the "Code Analysis" tab.

This feature is in response to the feedback we received that the number of rules is overwhelming and difficult to configure.

For this preview release we have focused on the core concept and made minimal changes to the UI.  In RTM we will have a new UI and a rich edit experience.  This release is all about getting your feedback.  Try out this feature on your code, use the built-in rule sets and let us know what you think.  Tell us what we missed or what rules you think are there and should not be.  Your real-life experience is our best guide for this feature. 

You can create a custom rule set to fine tune the exact rules to use.  If you think we should include your custom rule set in the out of the box sets then we want to hear from you (feedback links below).  Just attach the exported file to your connect bug or mail us.

Some useful links:

  • Release Post from JeffBe and download instructions - here
  • Feedback - bugs and suggestions can be submitted via http://connect.microsoft.com/visualstudio. Make sure when you submit issues through Connect that you indicate the product version as being “Visual Studio Team System Code Name “Rosario” (November 2007 CTP)”. That will ensure it gets to the right folks for consideration.
  • Questions - we’ve created a special forum specifically focused on Rosario: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=1736&SiteID=1 or you can respond to this blog post.

We look forward to hearing from you and hope you enjoy this new feature.

Come chat with the Code Analysis team tomorrow

$
0
0

Join members of the Visual Studio Team System product group to discuss features available in Team Foundation Server, Team Suite, Architecture Edition, Development Edition, Database Edition, and Test Edition. In addition, discuss what's new for these editions for Visual Studio 2008.

We will be holding two sessions:

Join the chat on Wednesday, December 5th, 2007 from 10:00am - 11:00am Pacific Time. Add to Calendar | Additional Time Zones

           -and-

Join the chat on Wednesday, December 5th, 2007 from 4:00pm - 5:00pm Pacific Time. Add to Calendar | Additional Time Zones

Reporting Code Analysis Defect Counts

$
0
0

    Code analysis defect counts are available in the cube that is part of the TFS Data Warehouse. This post shows you how to hook up Excel to show code analysis counts in a pivot table.

    First off you need to connect Excel up to the data warehouse that has the data. Under the Data tab in Excel select From Other Sources, From Analysis Services.

    clip_image001

    Then you need to give the name of the server with the data warehouse. In the standalone TFS case this will be whatever machine is running TFS. Assuming you have read permissions with your Windows account you can click Next, otherwise enter a user name and password that has access to the server and click Next.

    clip_image002

    Then, select the database (usually TfsWarehouse) and select the Build table.

    clip_image003

    Click Next and then supply whatever additional information that will help you remember this data connection.

    clip_image004

    Click Finish. Then define how you want to show the data in Excel - e.g. a pivot table.

    clip_image005

    Click OK which gives you the following:

    clip_image006

    In the PivotTable Field List, Expand Build Project where you will find two fields: Static Analysis Errors and Static Analysis Warnings:

    clip_image007

    You can click the checkboxes to add these to the values for your table. In most cases Static Analysis Warnings would be the most useful since Static Analysis Errors would typically stop the build.

    To complete the picture you can play with the pivot table and pivot and filter as you see fit. As a simple example you can add the Build field:

    clip_image008

    Which will give you one row per build in the pivot table.

    clip_image009

    Of course this data can be combined with other build data and charted etc. according to your needs. We are considering what reporting to provide in future versions so would love to hear your feedback on this feature and what you would like to see.


FAQ: Which Code Analysis rules shipped in which version?

$
0
0

In response to a lot of recent requests, we've put together a complete list of rules that shipped in the different versions of Visual Studio Code Analysis and FxCop. Attached is an Excel worksheet providing this information for Visual Studio 2005, Visual Studio 2008, FxCop 1.35 and FxCop 1.36 Beta.

One of things you'll notice as you read through the list is that we removed some rules from the later versions. There are a few reasons for this:

  • Noise and applicability. We use feedback from customers, SQM data (to see which rules users turn off), and input from internal teams (Windows, Office, CLR, etc) to determine the rules that are noisy without adding any perceivable value. There are also rules that are either no longer applicable or can no longer fire. for example, a rule could have been firing on a limitation of the CLR which has since been fixed in later versions.

  • Merged rules. Sometimes it makes sense to merge rules that fire on similar things, for example, the analysis in SecureGetObjectDataOverrides was already covered by OverrideLinkDemandsShouldBeIdenticalToBase, so these two rules were merged. Similarly, LongAcronymsShouldBePascalCased, ShortAcronymsShouldBeUppercase and IdentifiersShouldBeCasedCorrectly all fired on the casing of identifiers, and hence were merged in the later.

  • Analysis engine removed. In Visual Studio 2008 and FxCop 1.36 we removed one of our analysis engines. This engine was removed for a variety of reasons; it increased analysis time (although the engine encompassed less than 5% our analysis, it took up 50% of our time-to-analyze), indeterministic results (results appearing and disappearing between runs), and bugs found within the engine (and hence the rules that depended on it) required huge architectural changes. We instead decided to invest the resources that we would have spent on fixing the old engine, on a new data flow analysis engine based on Phoenix, which we will ship in a future version of Visual Studio.

There are also more differences between Visual Studio Code Analysis and FxCop than just the rules - in a future blog post I will cover these in detail.

What do you want to see in the second edition of Framework Design Guidelines?

$
0
0
Framework Design Guidelines, Second Edition

Krzysztof and Bradhave announced they are working on the second edition of the awesome Framework Design Guidelines and are looking for feedback on what they should put in it.

For those that don't know, a lot of our Code Analysis rules are based on the writings in this great book, so expect to see additional rules in the future based on the new guidelines in the second edition.

 To provide feedback, head over to Krzysztof's blog and post a comment.

Tutorial on writing your own Code Analysis rule

$
0
0

Jason Kresowaty has posted a great tutorial on writing Code Analysis/FxCop rules. He also spends time on explaining parts of the Introspection API, including the different nodes and their relationship to each other.

It's a great read, even if you've written some Code Analysis rules before. Definitely recommended.

What happened to the download and documentation of FxCop 1.35?

$
0
0

Update: You can now download FxCop 1.35 directly from MSDN Code Gallery

As you many you have well noticed, GotDotNet was officially retired last month now that the last of its functionality was superceded by MSDN Code Gallery. Unfortunately, at the same time, the FxCop team page, the download for FxCop 1.35 and the rule documentation was also removed.

We were told last year about the deprecation of GotDotNet and we had hoped that by now we would have had a new team site on MSDN, however, a variety of factors, some within our control and some beyond our control, prevented that from happening in time.

In the meantime, while we sort out new home for our beloved FxCop, here are a couple of workarounds:

To download FxCop

  • Upgrade to FxCop 1.36 Beta. This is one of our most stable beta's to-date; which is not surprising considering that some of the same bits also shipped in Visual Studio 2008. Go ahead, download FxCop 1.36 today - you won't be disappointed.

  • Download the Windows SDK. The Windows SDK includes the FxCop 1.35 setup. You might already have it installed if you have Visual Studio 2008, otherwise, download it. Either way, once installed, FxCop 1.35 setup can be found via Start -> All Programs -> Microsoft Windows SDK [Version] -> Tools -> Install Microsoft FxCop.

 To view the documentation

  • MSDN Library. Both the FxCop documentation and rule documentation are available on the MSDN Library.

  • Installed Help. FxCop 1.35 comes with a CHM (pronounced 'chum') containing FxCop and rule documentation. Albeit a little out-of-date when compared to the online version, access it via Start -> All Programs -> Microsoft FxCop 1.35 -> FxCop Documentation or via Help -> Using Microsoft FxCop inside FxCop.

FAQ: How do I prevent FxCop 1.36 from firing warnings against generated code?

$
0
0

I've upgraded from FxCop 1.35 to 1.36 and now FxCop has started to fire warnings against typed DataSets and other generated code. How do I turn this off?

The reason this is occurring is because we changed the way that FxCop analyzed generated code. Whereas previously in 1.35, FxCop would only ignore particular generated code (such as DataSets), FxCop 1.36 will now either ignore no generated code, or all generated code. The former is the default.

To change this behavior and have FxCop skip over generated code:

Using an FxCop project:

  1. Open your FxCop project in FxCop
  2. Choose Project -> Options -> Spelling & Analysis
  3. Check Suppress analysis results against generated code
  4. Click OK

Via the command-line:

  1. Pass the /ignoregeneratedcode switch, for example:

    FxCopCmd.exe /file:MyAssembly.dll /out:AnalysisResults.xml /ignoregeneratedcode

For more information on FxCop's behavior over generated code, see Correct usage of the CompilerGeneratedAttribute and the GeneratedCodeAttribute.

FxCop 1.35 now available (again) for download

$
0
0

We've just uploaded FxCop 1.35 to MSDN Code Gallery after we lost our home on GotDotNet - this is for those teams that either do not want to or just aren't ready to upgrade to FxCop 1.36 Beta.

For those that are already using FxCop 1.35, you'll probably notice that we flicked the switch to cause it to prompt you to download FxCop 1.36. We've love you to download it and try it out (it can be installed side-by-side without any issues with FxCop 1.35). If you hit any bugs, issues or just have some feedback about the new or existing versions of FxCop, feel free to head over to the Code Analysis forum and post away.

David Kean's new blog


FxCop 1.36 Released!

$
0
0

We are pleased to announce that we've released the next version of FxCop. This release has a number of changes since FxCop 1.36 Beta 2, including, but not limited to, the following:

  • Bug fixes that reduce noise, missing analysis and rule crashes.
  • New portability rule: Use Only API from Targeted Framework.  This rule will fire when the target assembly taking a dependency on a new API only included in a later version or in a service pack.
    • New option for new portability rule for selecting target framework for analysis.
      • Set the target framework in the UI via Project -> Option -> Spelling & Analysis -> Target Framework
      • Set the target framework on the command-line via the /targetframeworkversion switch. e.g: /targetframeworkversion:v2.0, /targetframeworkversion:v3.0, or /targetframeworkversion:v3.5

Compared with FxCop 1.35, FxCop 1.36 Beta 2 had changes including, but not limited to, the following:

  • 200+ bug fixes that reduce noise, missing analysis and rule crashes
  • New option for skipping analysis over tool generated code 
    • Turn this on in the UI via Project -> Options -> Spelling & Analysis -> Suppress analysis results against generated code
    • Turn this on on the command-line via the /ignoregeneratedcode switch. 
  • Better support for C++/CLI and the Compact Framework
  • Language 'friendly' API names in the UI and resolutions (ie Visual Basic syntax if running over a Visual Basic binary)
  • New globalization, design and usage rules
  • Performance improvements that cut analysis by 2x and use half as much memory
  • Documentation that is now available on MSDN

There are also some other underlying changes that we will talk about in some future posts. 

 

Download it, and tell us what you think. If you have any feedback, bug reports or any questions, feel free to head over to the Code Analysis forum and ask away.

 

 

Note:  If you already have FxCop 1.36 Beta 2 installed, please uninstall it first before you install FxCop 1.36. Otherwise, you may see an error when you install FxCop 1.36 on top of FxCop 1.36 Beta 2.

If you accidentally install FxCop 1.36 without uninstalling FxCop 1.36 Beta 2, please go to Add/Remove program to uninstall FxCop 1.36, and reinstall FxCop 1.36.

[EDIT] Note: FxCop 1.36 RTM shipped with additional tracing turned on.  This can make the FxCop output harder to read.  To turn tracing off, edit the FxCop.exe.config or FxCopCmd.exe.config files in the FxCop install directory.  Find the line that contains <add name="Trace" value="2" /> and change the "2" to "0".

New for Visual Studio 2008 SP1 and FxCop 1.36 – Multi-targeting rule

Fun with Code Analysis Rule Sets

$
0
0

Two weeks ago, I introduced you to Visual Studio 2010 September '08 CTP (Community Technology Preview). This CTP is available as a Virtual PC (VPC) image which can be downloaded at http://go.microsoft.com/fwlink/?LinkId=129231. The goal of the Community Technology Preview is to obtain feedback from our customers on the new scenarios we have enabled.  If you haven't already downloaded the CTP, do it now and take it out for a spin. 

There are many new cool features with the CTP such as an Historical Debugger and Impact Analysis of code changes, but today we are going to focus on Rule Sets for code analysis. (For an overview of all the neat stuff happening in code analysis, check out this PDC video http://mschnlnine.vo.llnwd.net/d1/pdc08/WMV-HQ/TL60.wmv )  Configuring code analysis in Visual Studio 2008 and earlier versions required evaluating each individual rule to determine whether it was important enough to turn on and fix for your project. This might be a very time-consuming process that made it difficult to make sure that the most important problems were identified and fixed. With rule sets, code analysis can now be configured much more quickly and easily with sets of rules that are targeted at specific scenarios or areas of emphasis. Let's take a look at how this works.

The following scenario comes from our CTP walkthrough.  You can find the walkthrough and more details when you download the CTP as described above.  Let's assume that you have the DinnerNow – Kiosk solution open and is the active project.  On the Analyze menu, click Configure Code Analysisfor DinnerNow.Restaurants.Kiosk.  The property page for Code Analysis is displayed:

 Code Analysis Properties

This screen tells us that Microsoft All Rules will be executed when we run code analysis, but what if we didn't want to run every Microsoft rule?  What if we have a specific scenario we wish to target?  We can change which rule set to run by clicking on Open which brings up:

Add or Remove Rule Sets

We can select which rule set(s) by simply selecting or deselecting the appropriate box.  Notice that each rule set has a brief description of the types of rules within the rule set.  Further, you can open up each individual rule set and see the specific rules that make up the rules sets.  You can also turn on or off individual rules within a rule set.  Finally, you can adjust the type of action a rule will trigger.  In the past, code analysis rules have been limited to build Warnings, but now you can elevate code analysis rules to build Errors.

As you can see, rules sets provide a powerful way to focus code analysis on the scenarios and rules that matter most to you.  You can also create custom rule sets based on your specific needs.  We wont go into it today, but if you download the CTP, the Walkthrough explains how to customize a rule set.

Give it a try and let us know what you think.

Cris

What’s new in Code Analysis for Visual Studio 2010

$
0
0

This post summarizes the new functionality you will experience sing the Code Analysis functionality in Visual Studio 2010. Note that Code Analysis is only available in the Premium and Ultimate editions of Visual Studio 2010.

Rule Sets

In Visual Studio 2010 you can manage the list of rules that are executed against your managed code using rule sets. Rule sets are persisted as xml files that may be included as part of your project or solution and checked into source code control along with your code. Visual Studio ships with several pre-defined rule sets

  • Basic Correctness
  • Basic Design Guidelines
  • Extended Correctness
  • Extended Design Guidelines
  • Globalization
  • Minimum Recommended
  • Security

The new rule set editor allows you to create your own custom rule sets. You access the rule set configuration dialog and rule set editor from the Project Properties \ Code Analysis tab. For more information on using rule sets see the MSDN documentation: http://msdn.microsoft.com/en-us/library/dd264949(VS.100).aspx.

You also have the ability to configure all projects in a solution to use the same rule set from the Solution Properties. See the MSDN documentation: http://msdn.microsoft.com/en-us/library/dd465181(VS.100).aspx.

New Rules

The following managed code analysis rules are new

CA1062

Validate arguments of public methods

CA1303

Do not pass literals as localized parameters

CA2000

Dispose objects before losing scope

CA2100

Review SQL queries for security vulnerabilities

CA2130

Security critical constants should be transparent

CA2131

Security critical types may not participate in type equivalence

CA2132

Default constructors must be at least as critical as base type default constructors

CA2133

Delegates must bind to methods with consistent transparency

CA2134

Methods must keep consistent transparency when overriding base methods

CA2135

Level 2 assemblies should not contain LinkDemands

CA2136

Members should not have conflicting transparency annotations

CA2137

Transparent methods must contain only verifiable IL

CA2138

Transparent methods must not call methods with the SuppressUnmanagedCodeSecurity attribute

CA2139

Transparent methods may not use the HandleProcessCorruptingExceptions attribute

CA2140

Transparent code must not reference security critical items

CA2140

Transparent code must not reference security critical items

CA2141

Transparent methods must not satisfy LinkDemands

CA2142

Transparent code should not be protected with LinkDemands

CA2143

Transparent methods should not use security demands

CA2144

Transparent code should not load assemblies from byte arrays

CA2145

Transparent methods should not be decorated with the SuppressUnmanagedCodeSecurityAttribute

CA2146

Types must be at least as critical as their base types and interfaces

CA2147

Transparent methods may not use security asserts

CA2149

Transparent methods must not call native code

CA2202

Do not dispose objects multiple times

CA2204

Literals should be spelled correctly

CA2215

Dispose methods should call base class dispose

CA2241

Provide correct arguments to formatting methods

Rules CA1062, CA1303, CA2000, CA2100, CA2202, CA2204, CA2215 and CA2241 are all implemented using the new Phoenix analysis engine. We’ll discuss the Phoenix engine in a subsequent blog post.

Metrics

We improved the accuracy of calculating several metrics for switch statements and catch blocks.

New errors and warnings that FxCopCmd will generate

The follow new error codes may be generated when FxCopCmd is unable to successfully analyze your code for one reason or another.

CA0061

The rule 'RuleId' referenced in rule set 'RuleSetName' could not be found.

CA0062

The rule 'RuleId' could not be found.

CA0063

Failed to load rule set file or one of its dependent rule set files.

CA0064

No analysis was performed because the specified rule set did not contain any FxCop rules.

CA0065

Unsupported metadata construct: Type 'TypeName' contains both a property and a field with the same name 'PropertyFieldName'

CA0066

The value '{0}' provided to the /targetframeworkversion is not a recognized version.

CA0067

Directory not found.

CA0068

Debug information could not be found for target assembly 'AssemblyName'.

CA0069

UsingAlternatePlatform. FrameworkVersion1 could not be found. Using FrameworkVersion2 instead. For best analysis results please ensure that the correct .NET Framework is installed.

CA0070

Unable to analyze permission attributes

 

Support for C# 4 language constructs

 

Support for C++ 0x language constructs

 

What’s gone

  • Policy Migration – TFS Checkin Policy

In Visual Studio 2008 you had the ability to copy your Code Analysis checkin policy settings from a TFS team project into the Solution / Project(s). This feature is not available in Visual Studio 2010. Use the new rule sets feature to configure the rules that will be executed during a build.

  • The following rules are no longer available

CA1805

Do not initialize unnecessarily

 

CA2127

Security transparent assemblies should not contain security critical code

Replaced by CA2136

CA2128

Security transparent code should not assert

Replaced by CA2147

CA2129

Security transparent code should not reference non-public security critical members

Replaced by CA2140

  • Managed C++ in-source suppression. Use the code analysis global suppression file. If you need the suppression attributes to be defined in your source code you will need to copy or move them from the global suppression file into your source code.

Conclusion

Questions and comments are welcome. You may either post a comment for this blog or post a question on the Code Analysis team’s MSDN forum.

 

The Visual Studio Code Analysis Team.

Comparison of Code Analysis Warnings and Errors - Visual Studio 2008 versus Visual Studio 2010

$
0
0

This blog compares the Code Analysis warnings and errors generated by Visual Studio 2008 and Visual Studio 2010.

 

Managed Code Analysis

 

Warning / Error

Number

Description

Visual Studio 2008 Team System

Visual Studio 2010 Premium

CA0001

An exception was raised within managed code analysis tool that does not indicate an expected error condition.

Yes

Yes

CA0051

No rules were selected.

Yes

Yes

CA0052

No targets were selected to analyze.

Yes

Yes

CA0053

Rule assembly could not be loaded.

Yes

Yes

CA0054

A custom rule assembly has invalid XML resources.

Yes

Yes

CA0055

Could not load file:<path>

Yes

Yes

CA0056

A project file has an incorrect version of the analysis tool.

Yes

Yes

CA0057

Violations cannot be mapped to the current set of targets and rules.

Yes

Yes

CA0058

Unable to load assemblies referenced.

Yes

Yes

CA0059

Command line switch error.

Yes

Yes

CA0060

Unable to load assemblies referenced indirectly.

Yes

Yes

CA0061

The rule 'RuleId' referenced in rule set 'RuleSetName' could not be found.

-

Yes

CA0062

The rule 'RuleId' could not be found.

-

Yes

CA0063

Failed to load rule set file or one of its dependent rule set files.

-

Yes

CA0064

No analysis was performed because the specified rule set did not contain any FxCop rules.

-

Yes

CA0065

Unsupported metadata construct: Type 'TypeName' contains both a property and a field with the same name 'PropertyFieldName'

-

Yes

CA0066

 -

Yes

CA0067

Directory not found.

-

Yes

CA0068

Debug information could not be found for target assembly 'AssemblyName'.

-

Yes

CA0069

UsingAlternatePlatform. FrameworkVersion1 could not be found. Using FrameworkVersion2 instead. For best analysis results please ensure that the correct .NET Framework is installed.

-

Yes

CA0070

Unable to analyze permission attributes

-

Yes

CA0501

Unable to read output report.

Yes

Yes

CA0502

Unsupported language.

Yes

Yes

CA0503

Additional warnings cannot be displayed.

Yes

Yes

CA0504

Rule directory was ignored because it does not exist

-

Yes

CA0505

The property is deprectated. Use the superceding property

-

Yes

CA1000

Do not declare static members on generic types

Yes

Yes

CA1001

Types that own disposable fields should be disposable

Yes

Yes

CA1002

Do not expose generic lists

Yes

Yes

CA1003

Use generic event handler instances

Yes

Yes

CA1004

Generic methods should provide type parameter

Yes

Yes

CA1005

Avoid excessive parameters on generic types

Yes

Yes

CA1006

Do not nest generic types in member signatures

Yes

Yes

CA1007

Use generics where appropriate

Yes

Yes

CA1008:

Enums should have zero value

Yes

Yes

CA1009

Declare event handlers correctly

Yes

Yes

CA1010

Collections should implement generic interface

Yes

Yes

CA1011

Consider passing base types as parameters

Yes

Yes

CA1012

Abstract types should not have constructors

Yes

Yes

CA1013

Overload operator equals on overloading add and subtract

Yes

Yes

CA1014

Mark assemblies with CLSCompliantAttribute

Yes

Yes

CA1016

Mark assemblies with AssemblyVersionAttribute

Yes

Yes

CA1017

Mark assemblies with ComVisibleAttribute

Yes

Yes

CA1018

Mark attributes with AttributeUsageAttribute

Yes

Yes

CA1019

Define accessors for attribute arguments

Yes

Yes

CA1020

Avoid namespaces with few types

Yes

Yes

CA1021

Avoid out parameters

Yes

Yes

CA1023

Indexers should not be multidimensional

Yes

Yes

CA1024

Use properties where appropriate

Yes

Yes

CA1025

Replace repetitive arguments with params array

Yes

Yes

CA1026

Default parameters should not be used

Yes

Yes

CA1027

Mark enums with FlagsAttribute

Yes

Yes

CA1028

Enum storage should be Int32

Yes

Yes

CA1030

Use events where appropriate

Yes

Yes

CA1031

Do not catch general exception types

Yes

Yes

CA1032

Implement standard exception constructors

Yes

Yes

CA1033

Interface methods should be callable by child types

Yes

Yes

CA1034

Nested types should not be visible

Yes

Yes

CA1035

ICollection implementations have strongly typed members

Yes

Yes

CA1036

Override methods on comparable types

Yes

Yes

CA1038

Enumerators should be strongly typed

Yes

Yes

CA1039

Lists are strongly typed

Yes

Yes

CA1040

Avoid empty interfaces

Yes

Yes

CA1041

Provide ObsoleteAttribute message

Yes

Yes

CA1043

Use integral or string argument for indexers

Yes

Yes

CA1044

Properties should not be write only

Yes

Yes

CA1045

Do not pass types by reference

Yes

Yes

CA1046

Do not overload operator equals on reference types

Yes

Yes

CA1047

Do not declare protected members in sealed types

Yes

Yes

CA1048

Do not declare virtual members in sealed types

Yes

Yes

CA1049

Types that own native resources should be disposable

Yes

Yes

CA1050

Declare types in namespaces

Yes

Yes

CA1051

Do not declare visible instance fields

Yes

Yes

CA1052

Static holder types should be sealed

Yes

Yes

CA1053

Static holder types should not have constructors

Yes

Yes

CA1054

URI parameters should not be strings

Yes

Yes

CA1055

URI return values should not be strings

Yes

Yes

CA1056

URI properties should not be strings

Yes

Yes

CA1057

String URI overloads call System.Uri overloads

Yes

Yes

CA1058

Types should not extend certain base types

Yes

Yes

CA1059

Members should not expose certain concrete types

Yes

Yes

CA1060

Move P/Invokes to NativeMethods class

Yes

Yes

CA1061

Do not hide base class methods

Yes

Yes

CA1062

Validate arguments of public methods

-

Yes

CA1063

Implement IDisposable correctly

Yes

Yes

CA1064

Exceptions should be public

Yes

Yes

CA1065

Do not raise exceptions in unexpected locations

Yes

Yes

CA1300

Specify MessageBoxOptions

Yes

Yes

CA1301

Avoid duplicate accelerators

Yes

Yes

CA1302

Do not hardcode locale specific strings

Yes

Yes

CA1303

Do not pass literals as localized parameters

-

Yes

CA1304

Specify CultureInfo

Yes

Yes

CA1305

Specify IFormatProvider

Yes

Yes

CA1306

Set locale for data types

Yes

Yes

CA1307

Specify StringComparison

Yes

Yes

CA1308

Normalize strings to uppercase

Yes

Yes

CA1309

Use ordinal StringComparison

Yes

Yes

CA1400

P/Invoke entry points should exist

Yes

Yes

CA1401

P/Invokes should not be visible

Yes

Yes

CA1402

Avoid overloads in COM visible interfaces

Yes

Yes

CA1403

Auto layout types should not be COM visible

Yes

Yes

CA1404

Call GetLastError immediately after P/Invoke

Yes

Yes

CA1405

COM visible type base types should be COM visible

Yes

Yes

CA1406

Avoid Int64 arguments for Visual Basic 6 clients

Yes

Yes

CA1407

Avoid static members in COM visible types

Yes

Yes

CA1408

Do not use AutoDual ClassInterfaceType

Yes

Yes

CA1409

Com visible types should be creatable

Yes

Yes

CA1410

COM registration methods should be matched

Yes

Yes

CA1411

COM registration methods should not be visible

Yes

Yes

CA1412

Mark ComSource interfaces as IDispatch

Yes

Yes

CA1413

Avoid non-public fields in COM visible value types

Yes

Yes

CA1414

Mark boolean P/Invoke arguments with MarshalAs

Yes

Yes

CA1415

Declare P/Invokes correctly

Yes

Yes

CA1500

Variable names should not match field names

Yes

Yes

CA1500

Variable names should not match field names

Yes

Yes

CA1501

Avoid excessive inheritance

Yes

Yes

CA1501

Avoid excessive inheritance

Yes

Yes

CA1502

Avoid excessive complexity

Yes

Yes

CA1502

Avoid excessive complexity

Yes

Yes

CA1504

Review misleading field names

Yes

Yes

CA1504

Review misleading field names

Yes

Yes

CA1505

Avoid unmaintainable code

Yes

Yes

CA1505

Avoid unmaintainable code

Yes

Yes

CA1506

Avoid excessive class coupling

Yes

Yes

CA1506

Avoid excessive class coupling

Yes

Yes

CA1600

Do not use idle process priority

Yes

Yes

CA1601

Do not use timers that prevent power state changes

Yes

Yes

CA1700

Do not name enum values 'Reserved'

Yes

Yes

CA1701

Resource string compound words should be cased correctly

Yes

Yes

CA1702

Compound words should be cased correctly

Yes

Yes

CA1703

Resource strings should be spelled correctly

Yes

Yes

CA1704

Identifiers should be spelled correctly

Yes

Yes

CA1707

Identifiers should not contain underscores

Yes

Yes

CA1708

Identifiers should differ by more than case

Yes

Yes

CA1709

Identifiers should be cased correctly

Yes

Yes

CA1710

Identifiers should have correct suffix

Yes

Yes

CA1711

Identifiers should not have incorrect suffix

Yes

Yes

CA1712

Do not prefix enum values with type name

Yes

Yes

CA1713

Events should not have before or after prefix

Yes

Yes

CA1714

Flags enums should have plural names

Yes

Yes

CA1715

Identifiers should have correct prefix

Yes

Yes

CA1716

Identifiers should not match keywords

Yes

Yes

CA1717

Only FlagsAttribute enums should have plural names

Yes

Yes

CA1719

Parameter names should not match member names

Yes

Yes

CA1720

Identifiers should not contain type names

Yes

Yes

CA1721

Property names should not match get methods

Yes

Yes

CA1722

Identifiers should not have incorrect prefix

Yes

Yes

CA1724

Type names should not match namespaces

Yes

Yes

CA1725

Parameter names should match base declaration

Yes

Yes

CA1726

Use preferred terms

Yes

Yes

CA1800

Do not cast unnecessarily

Yes

Yes

CA1801

Review unused parameters

Yes

Yes

CA1802

Use literals where appropriate

Yes

Yes

CA1804

Remove unused locals

Yes

Yes

CA1805

Do not initialize unnecessarily

Yes

No

CA1806

Do not ignore method results

Yes

Yes

CA1809

Avoid excessive locals

Yes

Yes

CA1810

Initialize reference type static fields inline

Yes

Yes

CA1811

Avoid uncalled private code

Yes

Yes

CA1812

Avoid uninstantiated internal classes

Yes

Yes

CA1813

Avoid unsealed attributes

Yes

Yes

CA1814

Prefer jagged arrays over multidimensional

Yes

Yes

CA1815

Override equals and operator equals on value types

Yes

Yes

CA1816

Call GC.SuppressFinalize correctly

Yes

Yes

CA1819

Properties should not return arrays

Yes

Yes

CA1820

Test for empty strings using string length

Yes

Yes

CA1821

Remove empty finalizers

Yes

Yes

CA1822

Mark members as static

Yes

Yes

CA1823

Avoid unused private fields

Yes

Yes

CA1824

Mark assemblies with NeutralResourcesLanguageAttribute

Yes

Yes

CA1900

Value type fields should be portable

Yes

Yes

CA1901

P/Invoke declarations should be portable

Yes

Yes

CA1903

Use only API from targeted framework

Yes

Yes

CA2000

Dispose objects before losing scope

-

Yes

CA2001

Avoid calling problematic methods

Yes

Yes

CA2002

Do not lock on objects with weak identity

Yes

Yes

CA2003

Do not treat fibers as threads

Yes

Yes

CA2004

Remove calls to GC.KeepAlive

Yes

Yes

CA2006

Use SafeHandle to encapsulate native resources

Yes

Yes

CA2100

Review SQL queries for security vulnerabilities

-

Yes

CA2101

Specify marshaling for P/Invoke string arguments

Yes

Yes

CA2102

Catch non-CLSCompliant exceptions in general handlers

Yes

Yes

CA2103

Review imperative security

Yes

Yes

CA2104

Do not declare read only mutable reference types

Yes

Yes

CA2105

Array fields should not be read only

Yes

Yes

CA2106

Secure asserts

Yes

Yes

CA2107

Review deny and permit only usage

Yes

Yes

CA2108

Review declarative security on value types

Yes

Yes

CA2109

Review visible event handlers

Yes

Yes

CA2111

Pointers should not be visible

Yes

Yes

CA2112

Secured types should not expose fields

Yes

Yes

CA2114

Method security should be a superset of type

Yes

Yes

CA2115

Call GC.KeepAlive when using native resources

Yes

Yes

CA2116

APTCA methods should only call APTCA methods

Yes

Yes

CA2117

APTCA types should only extend APTCA base types

Yes

Yes

CA2118

Review SuppressUnmanagedCodeSecurityAttribute usage

Yes

Yes

CA2119

Seal methods that satisfy private interfaces

Yes

Yes

CA2120

Secure serialization constructors

Yes

Yes

CA2121

Static constructors should be private

Yes

Yes

CA2122

Do not indirectly expose methods with link demands

Yes

Yes

CA2123

Override link demands should be identical to base

Yes

Yes

CA2124

Wrap vulnerable finally clauses in outer try

Yes

Yes

CA2126

Type link demands require inheritance demands

Yes

Yes

CA2127

Security transparent assemblies should not contain security critical code

Yes

No

CA2128

Security transparent code should not assert

Yes

No

CA2129

Security transparent code should not reference non-public security critical members

Yes

No

CA2130

Security critical constants should be transparent

-

Yes

CA2131

Security critical types may not participate in type equivalence

-

Yes

CA2132

Default constructors must be at least as critical as base type default constructors

-

Yes

CA2133

Delegates must bind to methods with consistent transparency

-

Yes

CA2134

Methods must keep consistent transparency when overriding base methods

-

Yes

CA2135

Level 2 assemblies should not contain LinkDemands

-

Yes

CA2136

Members should not have conflicting transparency annotations

-

Yes

CA2137

Transparent methods must contain only verifiable IL

-

Yes

CA2138

Transparent methods must not call methods with the SuppressUnmanagedCodeSecurity attribute

-

Yes

CA2139

Transparent methods may not use the HandleProcessCorruptingExceptions attribute

-

Yes

CA2140

Transparent code must not reference security critical items

-

Yes

CA2141

Transparent methods must not satisfy LinkDemands

-

Yes

CA2142

Transparent code should not be protected with LinkDemands

-

Yes

CA2143

Transparent methods should not use security demands

-

Yes

CA2144

Transparent code should not load assemblies from byte arrays

-

Yes

CA2145

Transparent methods should not be decorated with the SuppressUnmanagedCodeSecurityAttribute

-

Yes

CA2146

Types must be at least as critical as their base types and interfaces

-

Yes

CA2147

Transparent methods may not use security asserts

-

Yes

CA2149

Transparent methods must not call native code

-

Yes

CA2200

Rethrow to preserve stack details

Yes

Yes

CA2201

Do not raise reserved exception types

Yes

Yes

CA2202

Do not dispose objects multiple times

-

Yes

CA2204

Literals should be spelled correctly

-

Yes

CA2205

Use managed equivalents of Win32 API

Yes

Yes

CA2207

Initialize value type static fields inline

Yes

Yes

CA2208

Instantiate argument exceptions correctly

Yes

Yes

CA2210

Assemblies should have valid strong names

Yes

Yes

CA2211

Non-constant fields should not be visible

Yes

Yes

CA2212

Do not mark serviced components with WebMethod

Yes

Yes

CA2213

Disposable fields should be disposed

Yes

Yes

CA2214

Do not call overridable methods in constructors

Yes

Yes

CA2215

Dispose methods should call base class dispose

-

Yes

CA2216

Disposable types should declare finalizer

Yes

Yes

CA2217

Do not mark enums with FlagsAttribute

Yes

Yes

CA2218

Override GetHashCode on overriding Equals

Yes

Yes

CA2219

Do not raise exceptions in exception clauses

Yes

Yes

CA2220

Finalizers should call base class finalizer

Yes

Yes

CA2221

Finalizers should be protected

Yes

Yes

CA2222

Do not decrease inherited member visibility

Yes

Yes

CA2223

Members should differ by more than return type

Yes

Yes

CA2224

Override equals on overloading operator equals

Yes

Yes

CA2225

Operator overloads have named alternates

Yes

Yes

CA2226

Operators should have symmetrical overloads

Yes

Yes

CA2227

Collection properties should be read only

Yes

Yes

CA2228

Do not ship unreleased resource formats

Yes

Yes

CA2229

Implement serialization constructors

Yes

Yes

CA2230

Use params for variable arguments

Yes

Yes

CA2231

Overload operator equals on overriding ValueType.Equals

Yes

Yes

CA2232

Mark Windows Forms entry points with STAThread

Yes

Yes

CA2233

Operations should not overflow

Yes

Yes

CA2234

Pass System.Uri objects instead of strings

Yes

Yes

CA2235

Mark all non-serializable fields

Yes

Yes

CA2236

Call base class methods on ISerializable types

Yes

Yes

CA2237

Mark ISerializable types with SerializableAttribute

Yes

Yes

CA2238

Implement serialization methods correctly

Yes

Yes

CA2239

Provide deserialization methods for optional fields

Yes

Yes

CA2240

Implement ISerializable correctly

Yes

Yes

CA2241

Provide correct arguments to formatting methods

-

Yes

CA2242

Test for NaN correctly

Yes

Yes

CA2243

Attribute string literals should parse correctly

Yes

Yes

 

FxCopCmd Errors

No changes between Visual Studio 2008 and Visual Studio 2010.

Warning / Error

Number

Description

Visual Studio Team System 2008

Visual Studio 2010 Premium

0x0

No errors

Yes

Yes

0x1

Analysis error

Yes

Yes

0x2

Rule exceptions

Yes

Yes

0x4

Project load error

Yes

Yes

0x8

Assembly load error

Yes

Yes

0x10

Rule library load error

Yes

Yes

0x20

Import report load error

Yes

Yes

0x40

Output error

Yes

Yes

0x80

Command line switch error

Yes

Yes

0x100

Initialization error

Yes

Yes

0x200

Assembly references error

Yes

Yes

0x400

BuildBreakingMessage

Yes

Yes

0x1000000

Unknown error

Yes

Yes

 

C/C++ Code Analysis

No changes between Visual Studio 2008 and Visual Studio 2010.

Warning / Error

Number

Description

Visual Studio Team System 2008

Visual Studio 2010 Premium

C6001

using uninitialized memory <variable>

Yes

Yes

C6011

dereferencing NULL pointer <name>

Yes

Yes

C6029

possible buffer overrun in call to <function>: use of unchecked value

Yes

Yes

C6031

return value ignored: <function> could return unexpected value

Yes

Yes

C6053

call to <function> may not zero-terminate string <variable>

Yes

Yes

C6054

string <variable> may not be zero-terminated

Yes

Yes

C6057

buffer overrun due to number of characters/number of bytes mismatch in call to <function>

Yes

Yes

C6059

Incorrect length parameter in call to <function>. Pass the number of remaining characters, not the buffer size of <variable>

Yes

Yes

C6063

missing string argument to <function> corresponding to conversion specifier <number>

Yes

Yes

C6064

missing integer argument to <function> corresponding to conversion specifier <number>

Yes

Yes

C6066

non-pointer passed as parameter <number> when pointer is required in call to <function>

Yes

Yes

C6067

parameter <number> in call to <function> must be the address of the string

Yes

Yes

C6200

index <name> is out of valid index range <min> to <max> for non-stack buffer <variable>

Yes

Yes

C6201

buffer overrun for <variable>, which is possibly stack allocated: index <name> is out of valid index range <min> to <max>

Yes

Yes

C6202

buffer overrun for <variable>, which is possibly stack allocated, in call to <function>: length <size> exceeds buffer size <max>

Yes

Yes

C6203

buffer overrun for buffer <variable> in call to <function>: length <size> exceeds buffer size

Yes

Yes

C6204

possible buffer overrun in call to <function>: use of unchecked parameter <variable>

Yes

Yes

C6209

using 'sizeof<variable1>' as parameter <number> in call to <function> where <variable2> may be an array of wide characters, did you intend to use character count rather than byte count?

Yes

Yes

C6211

Leaking memory <pointer> due to an exception. Consider using a local catch block to clean up memory

Yes

Yes

C6214

cast between semantically different integer types: HRESULT to a Boolean type

Yes

Yes

C6215

cast between semantically different integer types: a Boolean type to HRESULT

Yes

Yes

C6216

compiler-inserted cast between semantically different integral types: a Boolean type to HRESULT

Yes

Yes

C6217

Implicit cast between semantically different integer types: testing HRESULT with 'not'. Consider using SUCCEEDED or FAILED macro instead

Yes

Yes

C6219

Implicit cast between semantically different integer types: comparing HRESULT to 1 or TRUE. Consider using SUCCEEDED or FAILED macro instead

Yes

Yes

C6220

warning C6220 - Implicit cast between semantically different integer types: comparing HRESULT to -1. Consider using SUCCEEDED or FAILED macro instead

Yes

Yes

C6221

Implicit cast between semantically different integer types: comparing HRESULT to an integer. Consider using SUCCEEDED or FAILED macros instead

Yes

Yes

C6225

Implicit cast between semantically different integer types: assigning 1 or TRUE to HRESULT. Consider using S_FALSE instead

Yes

Yes

C6226

Implicit cast between semantically different integer types: assigning -1 to HRESULT. Consider using E_FAIL instead

Yes

Yes

C6230

implicit cast between semantically different integer types: using HRESULT in a Boolean context

Yes

Yes

C6235

(<non-zero constant> || <expression>) is always a non-zero constant

Yes

Yes

C6236

(<expression> || <non-zero constant>) is always a non-zero constant

Yes

Yes

C6237

(<zero> && <expression>) is always zero. <expression> is never evaluated and may have side effects

Yes

Yes

C6239

(<non-zero constant> && <expression>) always evaluates to the result of <expression>. Did you intend to use the bitwise-and operator?

Yes

Yes

C6240

(<expression> && <non-zero constant>) always evaluates to the result of <expression>. Did you intend to use the bitwise-and operator?

Yes

Yes

C6242

A jump out of this try-block forces local unwind. Incurs severe performance penalty

Yes

Yes

C6244

local declaration of <variable> hides previous declaration at <line> of <file>

Yes

Yes

C6246

Local declaration of <variable> hides declaration of same name in outer scope. Additional Information: See previous declaration at <location>.

Yes

Yes

C6248

setting a SECURITY_DESCRIPTOR’s DACL to NULL will result in an unprotected object

Yes

Yes

C6250

Calling <function> VirtualFree without the MEM_RELEASE flag may free memory but not address descriptors (VADs); results in address space leaks

Yes

Yes

C6255

_alloca indicates failure by raising a stack overflow exception. Consider using _alloca_s instead

Yes

Yes

C6258

using TerminateThread does not allow proper thread clean up

Yes

Yes

C6259

labeled code is unreachable: (<expression> & <constant>) in switch-expr cannot evaluate to <case-label>

Yes

Yes

C6260

sizeof * sizeof is almost always wrong, did you intend to use a character count or a byte count?

Yes

Yes

C6262

Function uses <constant> bytes of stack: exceeds /analyze:stacksize<constant>. Consider moving some data to heap

Yes

Yes

C6263

using _alloca in a loop; this can quickly overflow stack

Yes

Yes

C6268

Incorrect order of operations: (<TYPE1>)(<TYPE2>)x + y. Possible missing parentheses in (<TYPE1>)((<TYPE2>)x + y)

Yes

Yes

C6269

possible incorrect order of operations: dereference ignored

Yes

Yes

C6270

missing float argument to <function>: add a float argument corresponding to conversion specifier <number>

Yes

Yes

C6271

extra argument passed to <function>: parameter <number> is not used by the format string

Yes

Yes

C6272

non-float passed as argument <number> when float is required in call to <function>

Yes

Yes

C6273

warning 6273 - non-integer passed as parameter <number> when integer is required in call to <function>: if a pointer value is being passed, %p should be used

Yes

Yes

C6274

non-character passed as parameter <number> when character is required in call to <function>

Yes

Yes

C6276

Cast between semantically different string types: char* to wchar_t*. Use of invalid string can lead to undefined behavior

Yes

Yes

C6277

NULL application name with an unquoted path in call to <function>: results in a security vulnerability if the path contains spaces

Yes

Yes

C6278

<variable> is allocated with array new [], but deleted with scalar delete. Destructors will not be called

Yes

Yes

C6279

<variable> is allocated with scalar new, deleted with array delete []

Yes

Yes

C6280

<variable> is allocated with <function>, but deleted with <function>

Yes

Yes

C6281

warning 6281 - incorrect order of operations: relational operators have higher precedence than bitwise operators

Yes

Yes

C6282

Incorrect operator: assignment of constant in Boolean context. Consider using '==' instead

Yes

Yes

C6283

<variable> is allocated with array new [], but deleted with scalar delete

Yes

Yes

C6284

object passed as parameter '%d' when string is required in call to <function>.

Yes

Yes

C6285

(<non-zero constant> || <non-zero constant>) is always a non-zero constant. Did you intend to use the bitwise-and operator?

Yes

Yes

C6286

(<non-zero constant> || <expression>) is always a non-zero constant. <expression> is never evaluated and may have side effects

Yes

Yes

C6287

redundant code: the left and right sub-expressions are identical

Yes

Yes

C6288

Incorrect operator: mutual inclusion over && is always zero. Did you intent to use || instead?

Yes

Yes

C6289

Incorrect operator: mutual exclusion over || is always a non-zero constant. Did you intend to use && instead?

Yes

Yes

C6290

Bitwise operation on logical result: ! has higher precedence than &. Use && or (!(x & y)) instead

Yes

Yes

C6291

Bitwise operation on logical result: ! has higher precedence than |. Use || or (!(x | y)) instead

Yes

Yes

C6292

ill-defined for-loop: counts up from maximum

Yes

Yes

C6293

Ill-defined for-loop: counts down from minimum

Yes

Yes

C6294

Ill-defined for-loop: initial condition does not satisfy test. Loop body not executed

Yes

Yes

C6295

Ill-defined for-loop: <variable> values are of the range "min" to "max". Loop executed indefinitely

Yes

Yes

C6296

Ill-defined for-loop: Loop body only executed once

Yes

Yes

C6297

Arithmetic overflow: 32-bit value is shifted, then cast to 64-bit value. Result may not be an expected value

Yes

Yes

C6298

using a read-only string <pointer> as a writable string argument: this will attempt to write into static read-only memory and cause random crashes

Yes

Yes

C6299

explicitly comparing a bit field to a Boolean type will yield unexpected results

Yes

Yes

C6302

format string mismatch: character string passed as parameter <number> when wide character string is required in call to <function>

Yes

Yes

C6303

format string mismatch: wide character string passed as parameter <number> when character string is required in call to <function>

Yes

Yes

C6305

potential mismatch between sizeof and countof quantities

Yes

Yes

C6306

incorrect call to <function>: consider using <function> which accepts a va_list as an argument

Yes

Yes

C6308

'realloc' may return null pointer: assigning a null pointer to <variable>, which is passed as an argument to 'realloc', will cause the original memory block to be leaked

Yes

Yes

C6309

argument <number> is null: it does not adhere to function specification of <function>

Yes

Yes

C6310

illegal constant in exception filter can cause unexpected behavior

Yes

Yes

C6312

Possible infinite loop: use of the constant EXCEPTION_CONTINUE_EXECUTION in the exception-filter expression of a try-except

Yes

Yes

C6313

Incorrect operator: Zero-valued flag cannot be tested with bitwise-and. Use an equality test to look for zero-valued flags

Yes

Yes

C6314

Incorrect order of operations: bitwise-or has higher precedence than the conditional-expression operator. Add parentheses to clarify intent

Yes

Yes

C6315

Incorrect order of operations: bitwise-and has higher precedence than bitwise-or. Add parentheses to clarify intent

Yes

Yes

C6316

Incorrect operator: tested expression is constant and non-zero. Use bitwise-and to determine whether bits are set

Yes

Yes

C6317

incorrect operator: logical-not (!) is not interchangeable with ones-complement (~)

Yes

Yes

C6318

Ill-defined __try/__except: use of the constant EXCEPTION_CONTINUE_SEARCH or another constant that evaluates to zero in the exception-filter expression. The code in the exception handler block is not executed

Yes

Yes

C6319

use of the comma-operator in a tested expression causes the left argument to be ignored when it has no side-effects

Yes

Yes

C6320

exception-filter expression is the constant EXCEPTION_EXECUTE_HANDLER. This may mask exceptions that were not intended to be handled

Yes

Yes

C6322

empty _except block

Yes

Yes

C6323

warning 6323 - use of arithmetic operator on Boolean type(s)

Yes

Yes

C6324

potential incorrect use of <function1>: Did you intend to use <function2>?

Yes

Yes

C6326

potential comparison of a constant with another constant

Yes

Yes

C6327

Potential buffer overrun: SysAllocStringLen copies <number> characters from the string <variable> without validating the number of characters to copy. The code may crash

Yes

Yes

C6328

warning C6328:<type> passed as parameter <number> when <type> is required in call to <function>

Yes

Yes

C6331

Invalid parameter: passing MEM_RELEASE and MEM_DECOMMIT in conjunction to <function> is not allowed. This results in the failure of this call

Yes

Yes

C6332

Invalid parameter: passing zero as the dwFreeType parameter to <function> is not allowed. This results in the failure of this call

Yes

Yes

C6333

Invalid parameter: passing MEM_RELEASE and a non-zero dwSize parameter to <function> is not allowed. This results in the failure of this call

Yes

Yes

C6334

sizeof operator applied to an expression with an operator may yield unexpected results

Yes

Yes

C6335

leaking process information handle <handlename>

Yes

Yes

C6336

arithmetic operator has precedence over question operator, use parentheses to clarify intent

Yes

Yes

C6381

Shutdown API <function> requires a valid dwReason or lpMessage

Yes

Yes

C6383

buffer overrun due to conversion of an element count into a byte count: an element count is expected for parameter <number> in call to <function>

Yes

Yes

C6384

dividing sizeof a pointer by another value

Yes

Yes

C6385

invalid data: accessing <buffer name>, the readable size is <size1> bytes, but <size2> bytes may be read: Lines: x, y

Yes

Yes

C6386

buffer overrun: accessing <buffer name>, the writable size is <size1> bytes, but <size2> bytes may be written: Lines: x, y

Yes

Yes

C6387

<argument> may be <value>: this does not adhere to the specification for the function <function name>: Lines: x, y

Yes

Yes

C6388

<argument> may not be <value>: this does not adhere to the specification for the function <function name>: Lines: x, y

Yes

Yes

C6400

Using <function name> to perform a case-insensitive compare to constant string <string name>. Yields unexpected results in non-English locales

Yes

Yes

C6401

Using <function name> in a default locale to perform a case-insensitive compare to constant string < string name>. Yields unexpected results in non-English locales

Yes

Yes

C6500

invalid annotation: value for <name> property is invalid

Yes

Yes

C6501

annotation conflict: <name> property conflicts with previously specified property

Yes

Yes

C6503

annotation conflict: references may not be marked Null=Yes or Null=Maybe

Yes

Yes

C6504

invalid annotation: property may only be used on values of pointer, pointer-to-member, or array type

Yes

Yes

C6505

invalid annotation: MustCheck property may not be used on values of void type

Yes

Yes

C6506

invalid annotation: <name> property may only be used on values of pointer or array types

Yes

Yes

C6507

annotation conflict: Null property at Deref=0 on a post condition must be a subset of the Null property on the precondition

Yes

Yes

C6508

invalid annotation: write access is not allowed on const values

Yes

Yes

C6509

invalid annotation: 'return' cannot be referenced from a precondition

Yes

Yes

C6510

invalid annotation: NullTerminated property may only be used on values of pointer or array type

Yes

Yes

C6511

invalid annotation: MustCheck property must be Yes or No

Yes

Yes

C6512

invalid annotation: Null property must be Maybe if the Valid property is No

Yes

Yes

C6513

invalid annotation: ElementSizeConst requires additional size properties

Yes

Yes

C6514

invalid annotation: value of the <name> property exceeds the size of the array

Yes

Yes

C6515

warning C6515 - invalid annotation: <name> property may only be used on values of pointer type

Yes

Yes

C6516

invalid annotation: no properties specified for <name> attribute

Yes

Yes

C6517

annotation conflict: ValidElementsConst and ValidBytesConst may not be specified on the buffers that are not readable

Yes

Yes

C6518

annotation conflict: WriteableElementsConst and WriteableBytesConst may not be specified on buffers that are not writable

Yes

Yes

C6521

invalid size specification: * operator can only be applied to pointer types

Yes

Yes

C6522

invalid size specification: expression must be of integral type

Yes

Yes

C6523

invalid size specification: parameter <name> not found

Yes

Yes

C6525

invalid size specification: property value may not be valid

Yes

Yes

C6526

warning C6526 - invalid size specification: expression must be of array or pointer type

Yes

Yes

C6530

warning 6530: unrecognized format string style <name>

Yes

Yes

C6535

buffer cannot be of size <n>, bigger than max(size_t)

Yes

Yes

Viewing all 35 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>