Unknown's avatar

About ericlippert

http://ericlippert.com

Coverity analysis and FXCOP

This has been a crazy busy week and its only Tuesday. I spent the weekend helping set up the new Coverity office on the 12th floor of the Columbia Center — more on that on Thursday, after I’ve had a chance to take some photos — and schmoozing with my old team at Microsoft as part of the MVP summit. I am super-excited to be a C# MVP, though it is a bit odd to be on the audience side rather than the presenter side for the summit. “Thank you Eric for holding onto the microphone for us for the last half hour” was Anthony‘s wry comment after one marathon Q&A session yesterday. Old habits die hard.

One of the questions I’ve gotten frequently, both here at the summit and at other events, is how Coverity’s analysis of C# programs compares to FXCOP. My “Ask the bug guys” colleague Jon has just written an article about that very subject, so check it out. The short version: by design, they do not overlap at all. We want these tools to be complementary, not competitors. (And in fact you can import FXCOP warnings into Coverity Connect to track them alongside of defect reports discovered by Coverity’s analysis.)

A practical use of multiplicative inverses

Last time we showed how you can take any two coprime positive integers x and m and compute a third positive integer y with the property that (x * y) % m == 1, and therefore that (x * z * y) % m == z % m for any positive integer z. That is, there always exists a “multiplicative inverse”, that “undoes” the results of multiplying by x modulo m. That’s pretty neat, but of what use is it?
Continue reading

ATBG: de facto and de jure reachability

UPDATE: Coverity has removed the dev testing blog; I’ve put in a link to the internet archive.


In the latest episode of the Coverity Development Testing Blog‘s continuing series “Ask the Bug Guys”, I dig into an interesting question about inconsistencies between de facto and de jure unreachability — that is, the difference between code that is actually unreachable and the smaller set of code that the C# compiler detects as unreachable. The difference can cause some interesting inconsistencies in the compiler’s behavior. And my colleague Jon ponders the wisdom of fixing fragile, hard-to-understand code even if it is at present correct.

As always, if you have questions about a bug you’ve found in a C, C++, C# or Java program that you think would make a good episode of ATBG, please send your question along with a small reproducer of the problem to TheBugGuys@Coverity.com. We cannot promise to answer every question or solve every problem, but we’ll take a selection of the best questions that we can answer and address them on the dev testing blog every couple of weeks.

Math from scratch, part twelve: Euclid and Bézout

Now that we have an integer library, let’s see if we can do some 2300-year-old mathematics. The Euclidean Algorithm as you probably recall dates from at least 300 BC and determines the greatest common divisor (GCD) of two natural numbers. The Extended Euclidean Algorithm solves Bézout’s Identity: given non-negative integers a and b, it finds integers x and y such that:

a * x + b * y == d

where d is the greatest common divisor of a and b. Obviously if we can write an algorithm that finds x and y then we can get d, and x and y have many useful properties themselves that we’ll explore in future episodes.

Continue reading

Math from scratch, part eleven: integer division

Now we come to the controversial one. As I pointed out back in 2011, the % operator is the remainder operator. When extending the division and remainder operators from naturals to integers, I require that the following conditions be true for dividend x, non-zero divisor y, quotient q and remainder r:

  • x == y * q + r
  • if x and y are non-negative then 0 <= r < y
  • (-x) / y == x / (-y) == -(x / y)

Let’s take a look at the consequences of these three facts. Continue reading

Math from scratch, part ten: integer comparisons

I’m going to use the same technique I used for Natural comparisons to do Integer comparisons: make a helper function that returns -1 if x < y, 0 if x == y and 1 if x > y, and then have every entry point simply call that helper function. This way we know that all the operators are consistent. The big difference here of course is that I do not need to have a special case that says that null sorts before any value. Continue reading

ATBG: null coalescing precedence

In the latest episode of the Coverity Development Testing Blog‘s continuing series “Ask the Bug Guys”, I dig into two questions about the null coalescing operator. This handy little operator is probably the least well understood of all the C# operators, but it is quite useful. Unfortunately, it is easy to accidentally use it incorrectly due to precedence issues.

As always, if you have questions about a bug you’ve found in a C, C++, C# or Java program that you think would make a good episode of ATBG, please send your question along with a small reproducer of the problem to TheBugGuys@Coverity.com. We cannot promise to answer every question or solve every problem, but we’ll take a selection of the best questions that we can answer and address them on the dev testing blog every couple of weeks.

Math from scratch, part eight: integers

The integers are an extension to the naturals that closes them over subtraction. Rather than do anything fancy, I’m simply going to say that an integer is a natural with an associated sign, and that zero is always “positive”. We don’t want to end up in a situation where there are two forms of zero, since that is confusing. (We could of course have three signs, positive, negative and zero, but, meh. We don’t gain any great benefits from having a third sign.)

This time however I’m going to make a struct. C# requires that default(SomeStruct), where all the fields are their default values, be a valid value of the type. The default should logically be zero, as it is with all the built-in number types. So rather than checking for null, as we did with the reference type Natural, I’m going to check the sign field for null, which will only be possible if we’ve got a default struct. We’ll simply replace that with zero. (I am in general opposed to modifying the formal parameters of a method; I prefer to treat them as read-only variables. I’ll make an exception in this case because it keeps the code short and clear.) Continue reading