Even more video

Here's another portion of the video interview that I shot over Christmas at Coverity headquarters in San Francisco.

In this bit I talk about the history of C#, how C#'s safety system is definitely a step in the right direction but not by any means a panacea, the most common defect patterns we find in C# code, the basic workflow for using the Coverity static analyzer, and finally a plug for this very blog. That's a lot to fit into seven minutes!

ATBG: method type inference with multiple interfaces

Today on the Coverity Development Testing Blog's continuing series Ask The Bug Guys, I take a question from an "Eric L", who is confused about one of the subtle rules of method type inference despite having written the rule himself. My colleague Jon takes a question from a beginner C programmer about memory allocation.

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.

ATBG: interfaces and increments

On today's episode of the Coverity Development Testing Blog series Ask The Bug Guys we have two posts. I take on the question does explicit interface implementation violate encapsulation? and my colleague Jon follows up on my previous posting about increment operators to discuss the precedence of the increment operator and bonus, the meaning of local static in C/C++.

As always: if you have a question about some aspect of C, C++, C# or Java programming language design, or want to share an interesting bug that bit you in one of those languages, please send it (along with a concise 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 here every couple of weeks.

ATBG meets math from scratch

In a nice bit of synchronicity my article this week on Ask The Bug Guys, our continuing series on the Coverity Development Testing Blog, is about the differences between the C, C++ and C# interpretation of the ++ operator1 So read that first, and then it will make perfect sense why the increment operator on my Natural class from last time is simply:

public static Natural operator ++(Natural x)
  if (ReferenceEquals(x, null))
    throw new ArgumentNullException("x");
  return Add(x, One);

As always, if you have a question about a bug in a C, C++, C# or Java program please email it to TheBugGuys@coverity.com along with a concise reproducer of the problem if possible. We can't answer every question but we'll pick a sample of the most interesting ones a post an analysis on the dev testing blog.

Next time on FAIC: multiplication.

  1. And of course everything in there applies equally well to the -- operator.

Verbatim identifiers

In C# you can preface any identifier or keyword with the @ symbol to make it a verbatim identifier. This allows you to use what would normally be reserved keywords, like for as identifiers, should you need to.

I'm occasionally asked why it is that any identifier can be made into a verbatim identifier. Why not restrict the verbatim identifiers to the reserved and contextual keywords?
Continue reading

What is the type of the null literal?

The C# 2.0 specification says

The null literal evaluates to the null value, which is used to denote a reference not pointing at any object or array, or the absence of a value. The null type has a single value, which is the null value.

But every version of the specification since then does not contain this language. So what then is the type of the null literal expression?

Continue reading

Why does a foreach loop silently insert an "explicit" conversion?

The C# specification defines

foreach (V v in x) 

as having the same semantics as:1

  E e = ((C)(x)).GetEnumerator();
    V v;  // Inside the while in C# 5.
    while (e.MoveNext()) 
      v = (V)e.Current;
    // necessary code to dispose e

There are a lot of subtleties here that we've discussed before; what I want to talk about today is the explicit conversion from e.Current to V. On the face of it this seems very problematic; that's an explicit conversion. The collection could be a list of longs and V could be int; normally C# would not allow a conversion from long to int without a cast operator appearing in the source code.2 What justifies this odd design choice?

Continue reading

  1. This is not exactly what the spec says; I've made one small edit because I don't want to get into the difference between the element type and the loop variable type in this episode.
  2. Or the long being a constant that fits into an int.